API Implementieren

[The_Searcher]

Hi,

ich hab mal eine Verständnis Frage zu low-level-API´s wie DX12 und Vulkan:

Ich hab gelesen das die API in der Befehlskette an der 2 Stelle steht:

Quellcode --> API --> Treiber --> CPU/GPU


Jetzt stellt sich mir aber folgende Frage: Ist die API unabhängig vom Quellcode? Sprich: Ist Sie ein eigenständiges Programm?
Oder ist die API als Quellcode ein Teil des Programms? Oder vielleicht beides?

Eine API ist ja dafür da, das man dem Computer sagt, wann und wie (Mit dem Hintergedanken der Effizenzsteigerung) er den Quelltext bzw. dem Binärcode ausführen soll. Wie implementiert man die API eigentlich in ein Spiel?

In einer Lizenzengine wie z.B. Unity kann man ja den Renderpfad auswählen, aber so einfach ist das doch nicht?

Ich weiß nicht ob der Sinn meiner Frage richtig rüberkommt, da ich vom Thema nicht so viel Ahnung habe und erst seit 1 Monat C++ lerne.

Meine Frage ist nur eine Frage zum Verständnis und nicht weil ich nach 1 Monat schon ein Spiel machen möchte ^^

MFG

 

[fotoman]

API steht für Application Programming Interface, also die Definition oder Beschreibung einer Programmierschnittstelle.

DX12, Vulkan, OpeGL und co definieren damit nur, was geschieht, wenn eine Applikation (z.B. ein Spiel) eine Funktion der API aufruft. Nicht aber, wie sie in einem Quelltext realisiert ist.

Wie implementiert man die API eigentlich in ein Spiel?

Das hat für mich dann schon nichts mehr mit "low-level-API" zu tun, mag aber heutzutage anders definiert werden.

DirectX, OpenGL, Vulkan und co. bieten durch ihre API gewisse Möglichkeiten, teils nur als HighLevel (definition von 3D-Modellen), teils auch tiefgreifender (Shader-Programmierung).

Grafik-Engines wie Unity bilden dann darauf (und auf vielem andern) eine Schnittstelle (beschrieben durch die API) zur Anwendung. So lange die low-level API eine Funktion unterstützt, wird diese genutzt (der Aufruf im Idealfall einfach durchgereicht), wenn nicht, wird die Funktion u.U. nachgebildet oder es gibt sie halt garnicht.

Ist die API unabhängig vom Quellcode?

Nachdem Du dabei zwei unabhängig Begriff vermischst, kann ich nur raten:
So lange eine Applikation eine Version einer API nutzt (also z.B. DX11), ist dies sowohl unabhängig von der Implementierung (also dem Quelltext) der Anwendung wie auch unabhängig von der Implementierung des Treibers.

So gibt es z.B. für OpenGL einige Implementierungen (z.B. nVidia, AMD, MESA). Die Quelltexte davon sind mit sicherheit unterschiedlich, die API ist aber mit OpenGL definiert.

Diese Implementierung der API greift dann wieder auf den Treiber der Grafikkarte zu. DX12 setzt auf Schnittstellen (=APIs) auf, die Microsoft für einen Grafiktreiber unter Windows definiert hat.

Quellcode --> API --> Treiber --> CPU/GPU

Das "Bild" ist einiges komplizierter:
Anwendung(*) nuttzt eine API -> high-level Trieber (DX12/OpenGL) (*) nutzt die API des Grafiktreibers -> low-level Grafiktreiber (*) nutzt die GPU oder CPU

Alle (*) sind ein eime Quelltextimplementiert (egal, ob das nun C++, C, Assembler oder sonstwas ist)
Zwischen die Anwendung und den high-level Treiber kann man jetzt noch eine Grafik-Engine wie Unity setzen, die wieder eine API für die Anwendung zur Verfügung stellt und die API des high-level Triebers nutzt.

Mit dem Hintergedanken der Effizenzsteigerung

Ob das bei einer gegebenen API auch funktioniert, muss man halt testen. Da mag es durchaus sein, dass z.B. die Generierung von Schatten oder Spiegelungen in der einen API vom Treiber (und damit im Idealfall von der Hardware) erledigt werden kann. Eine andere HW unterstützt dies aber nicht direkt, weshalb es der Programmierer des Grafiktreibers simulieren muss., will es seine Grafikkarte trotzdem als "kompatibel" verkaufen. Und hat dann ein Hersteller kenie große Lust dazu (wie jahrelang bei AMD und OpenGL), dann ist die OpenGL API zwar vollständig implementiert, aber so unendlich langsam,, dass sie keiner nutzen will.

 

[The_Searcher]

Erstmal vielen Dank für deine schnelle Antwort

Damit ich das richtig verstehe: Eine API ist eine Sammlung von Funktionen (Beispiel: Direct X 12 feature lvl?) welche von der Hardware direkt ausgeführt werden kann?

Oder bin ich (wieder) auf dem totalen Holzweg ^^ ?

 

[fotoman]

Damit ich das richtig verstehe: Eine API ist eine Sammlung von Funktionen (Beispiel: Direct X 12 feature lvl?) welche von der Hardware direkt ausgeführt werden kann?

Teil 1 stimmt, Teil 2 nicht zwingend (je nachdem, wie ich "kann" verstehe).

Eine API beschreibt einen Satz an möglichen Funktionen, also z.B. (vereinfacht auf 2D gesehen)
Lösche den Bildschirm
zeichne einen Punkt
zeichne eine Linie
zeichne ein Rechteck

Das Programm ruft nur die API-Funktion zun Löschen und danach zum Zeichnen des Rechtecks auf.

Falls die GPU das alles selber kann, dann wird DirectX die entsprechende API des Grafiktreibers aufrufen und diese wird über die GPU alles erledigen.

Kann die Grafikarte das nicht oder die API des Grafiktreibers bietet keine Funktion dazu, dann macht DirectX alles selber. Die Grafikkarte ist dann nur in der Lage, einen Speicherbereich auszulesen und in ein Signal für den Monitor zu wandeln, damit man etwas sieht.

Dann würde DX intern folgendes machen:
- den Speicherbereich für den Bildschirm mit Nullen beschreiben
- zum Zeichnen des Rechtecks viermal eine Linie zeichnen
- zum Zeichnen einer Linie einen "passenden" Algorithmus wählen und jeden Pixel über die Funktion "zeichne einen Pixel" in den Speicher schreiben.

Die Applikation bekommt davon nichts mit, der Anwender sieht, dass alles unendlich langsam wird (ähnlich so, wie wenn man ein VM ohne VMWare-Tools nutzt)

Das ganze dann noch erweitert um eine Spiele-Engine, die u.U. das Spiel dabei unterstützt einen Ball physikalisch korrekt zu bewegen.
Das Spiel sagt der Spiele-Engine:
- bewege den Ball mit der Kraft in die Richtung
die Spiele Engine berechnet daraus eine pyhsikalisch korrekte Bahn für den Ball und sagt DirectX:
- lösche den alten Ball
- zeichne den Ball an der neuen Stelle
- das ganze innerhalb der Spiele-Engine in vielen kleinen Schritten, bis der Ball entweder zum Stilstand kommt oder bis das Spiel wieder neue Anweisungen gibt. Da die Spiel-Engine die gesamte "Umgebung" kennt (z.B. das obige Rechteck) kann sie auch noch Kollisionserkennung mit einbauen und den Ball an einer der Linien abprallen lassen.

Dieser Berechnungsteil kann mittlerweile bei neueren Gragfikkarten/Treibern/APIs standardisiert über die GPU ausgeführt werden (z.B. mittles PhysX). Für andere Karten wird sich die Spiele-Engine u.U. dazu entscheiden, einige Berechnungen auf der Grafikkarte durchführen zu lassen, da die aktuelle Version von DirectX sowas unabhängig von Cuda oder OpenCL direkt und einheitlich für alle Grafikkarten unterstützt.

 

[VikingGe]

Erstmal sollten wir glaube ich klären, dass sich der Begriff API längst nicht ausschließlich auf Direct3D und Vulkan beschränkt, sondern generell für Bibliotheken, Funktions- und Klassensammlungen genutzt wird und auch mit Hardware erstmal nicht viel zu tun hat. Wenn du wirklich ein Spiel von Grund auf programmieren willst, wirst du dich mit vielen APIs für viele verschiedene Zwecke herumschlagen müssen - bei den genannten APIs handelt es sich nur um standartisierte (!) Schnittstellen zur Programmierung von GPUs, für die verschiedene Implementierungen existieren.

Die Erklärung von fotoman ist aber gut, um zu illustrieren, wie das ganze im Falle der Grafik-APIs grundsätzlich funktioniert.

 

[DataDino]

Zumal der Begriff implementieren auch wieder eine Wissenschaft für sich ist.

Im Bezug auf die Grafik-API's hat fotoman schon einen sehr guten groben Überblick gegeben. Einen detaillierten wirste aber nur in Büchern oder sehr umfangreichen Tutorials/Wikis bekommen.

VikingGe spricht da aber auch einen sehr wichtigen Teil an. Man sollte grundlegend sich dem Begriff API bewusst werden. API's stellen grundlegend Schnittstellen zu abweichenden Technologien dar, die durch API's für die selbstgewählte zugänglich gemacht wurden. Wenn du also eine dieser Grafik-API's verwenden möchtest, benötigst du natürlich auch die nötigen Bibliotheken dafür. Für die bekanntesten Sprachen existieren diese Bibliotheken natürlich. DirectX befinden sich glaube ich im DX-SDK (glaub ich - hatte damit nie wirklich zu tun), OpenGL sowie Vulkan lassen sich aus dem Netz beziehen. Diese werden wie jede andere Klassenbibliothek auch im Kopf des Quellcodes eingehängt und können im Quellcode der Zielanwednung verwendet werden.

Wie allerdings API's verwendet werden, ist kein Standard. Web-Anwendungen zum Beispiel stellen auch API's zur verfügung, für die man zwangsläufig keine Bibliotheken benötigt (z.B. PHP-BB bzw. Bulletin-Board und Tapatalk). Hier wird das ganze über einen Webservice erledigt (wahrscheinlich mit REST). Kommuniziert wird dann über die klassischen HTTP-Requests, die man relativ einfach mittlerweile über fast jede Sprache verwenden kann.

Auch bereits fertige Programme stellen eine API zur Verfügung. Diese nutzt man dann, wenn man für diese Programme Plugins (z.B. Firefox, Chrome oder Photoshop) oder Makros (z.B. MS Office, LibreOffice oder WoW <- Wenn es das noch gibt) schreibt. Die benötigen aber oftmals das zusätzliche Einhängen von externen Bibliotheken nicht mehr.

Aber um auf den Kern Grafik-API's zurückzukommen:
Das arbeiten mit diesen API's ist eine sehr umfangreiche und meist auch sehr langwierige/anstrengende Geschichte. Vor allem dann, wenn man den Anspruch hat, an heutige optische Qualitäten der Spiele heranzukommen. Wenn man also nicht alleine ist und eine Middleware schreiben will oder das ganze für Studium/Ausbildung benötigt, würde ich mich persönlich dann nicht mehr als nötig mit den Low-Level-API's beschäftigen, sondern direkt auf Middleware setzen (Als Middleware werden übrigens die Engines bezeichnet). Solltest du dir das aber trotzdem antun wollen, benötigst du zum einen entweder ein Buch oder gute Englischkenntnisse für Tutorials/Wikis/Onlinemanuals und vor allem sehr sehr sehr viel Kaffee.

 

[The_Searcher]

Vielen Dank für die vielen Umfangreichen Antworten
Echt Top von euch

Wenn man also nicht alleine ist und eine Middleware schreiben will oder das ganze für Studium/Ausbildung benötigt, würde ich mich persönlich dann nicht mehr als nötig mit den Low-Level-API's beschäftigen, sondern direkt auf Middleware setzen (Als Middleware werden übrigens die Engines bezeichnet).

Wenn eine Engine jetzt z.B. Vulkan unterstützt, dann heißt das am Ende nur das man die entsprechenden Vulkan Funktionen/ Features benutzen kann oder?

 

[bingo88]

Das hängt von der Engine ab. Bei manchen Engines bekommst du von der genutzten Grafik-API nichts mit, da arbeitest du dann implizit mit diesem Features, bei anderen hat man mehr oder weniger direkten Zugriff auf die Grafik-API.

 

[DataDino]

Wenn eine Engine jetzt z.B. Vulkan unterstützt, dann heißt das am Ende nur das man die entsprechenden Vulkan Funktionen/ Features benutzen kann oder?

Jein! Middleware/Engines stellen meist keinen direkten Zugang zur LL Grafik-API zur Verfügung. Schotten sie aber nicht ab. Heutige Engines arbeiten meist stark abstrahiert und erst beim erzeugen des fertigen Produkts (Deployment) werden die nötigen Bibliotheken verlinkt/eingehängt. Ob dann während der Entwicklung auch im Code Zugriff auf die LL-API's möglich ist, kann ich pauschal nicht sagen. Man arbeitet heutzutage mehr mit Editoren und scriptet bei den meisten Engines per Module und Drag & Drop (z.B. Unreal Engine oder CryEngine etc. pp.). Man kann also sagen, das Spieleentwicklung mittlerweile wieder zu einem eher kreativen Prozess geworden ist und weniger technisch abläuft.

Die Engines verwenden je nach gewähltem Renderpfad die entsprechenden Bibliotheken, um die Grafikausgabe zu rendern. Man muss selbst als Spieleentwickler auf diese Prozesse nicht zwangsläufig einfluss nehmen. Es würde mich also nicht wundern, das bei den noch eher mageren DX 12 und Vulkan-Vorteilen, von denen man oftmals liest, genau an der Stelle der Hund begraben liegt. Um also auf die Frage zurückzukommen: Die Engines verwenden die Features von z.B. Vulkan. Aber ob alle Features von der Engine genutzt werden und ob man selbst auf Vulkan-Features zugreifen kann, hängt von der Engine ab und kann ich nicht pauschal beantworten.

PS: Auch für Linux kann man viele Engines nutzen. Das konzentriert sich also nicht nur auf Windows (auf Signatur schau ): Game Engines - GamingOnLinux.com Linux Games Wiki

Aber ich würde mich nicht nur auf Vulkan versteifen. OpenGL funktioniert auch auf allen 3 bekannten Systemen.

 

[VikingGe]

OpenGL funktioniert auch auf allen 3 bekannten Systemen.

OpenGL ist unter Mac OS X genau so wenig nutzbar wie Vulkan, wenn du nicht gerade in die Steinzeit zurück möchtest.

 

[DataDino]

OpenGL ist unter Mac OS X genau so wenig nutzbar wie Vulkan, wenn du nicht gerade in die Steinzeit zurück möchtest.

Das steht wieder auf einem andern Blatt Papier. Am Ende entscheidet es sowieso der eigene Anspruch und die Anforderungen. Und wenn Vulkan mit Mac OSX auch nicht so kann, dann ist das am Ende sowieso egal, ob Vulkan oder OpenGL. Da er ja anscheinend eher mit Linux arbeiten zu scheint, fällt DirectX eh raus. Viel bleibt dann auch nicht mehr.

 

[The_Searcher]

PS: Auch für Linux kann man viele Engines nutzen. Das konzentriert sich also nicht nur auf Windows (auf Signatur schau )

^^

Ich bin daran interessiert das sich Linux sich als Gaming Plattform durchsetzt ^^.
Deswegen sollte man selbst als gutes Beispiel vorangehen

Ich bin einfach nicht mit der Windows 10 Politik von Microsoft einverstanden. Und wenn man alles frisst was MS dir vor die Füße wirft, dann wird sich das auch nie ändern.

Deswegen werd ich DirectX auch gekonnt ignorieren


Was gibt es noch wichtiges über diese Thema zu wissen? Eure Erklärungen sind wirklich sehr interessant

 

[DataDino]

Ich bin einfach nicht mit der Windows 10 Politik von Microsoft einverstanden. Und wenn man alles frisst was MS dir vor die Füße wirft, dann wird sich das auch nie ändern.

Ich habe auch mal eine ganze Weile so gedacht. Und ich respektiere deine Einstellung und finde sie auch gut. Lass dir aber von jemanden, der vor Jahren den Kampf schon aufgegeben hat gesagt sein, das du da gegen totale Windmühlen kämpfst. Du musst dir dabei vor Augen führen, das du nicht gegen ein Unternehmen oder ein Produkt eines Unternehmen kämpst. Sondern du kämpfst gegen zwei viel mächtigere Feinde. Zum einen den Verbraucher/Kunden/Konsumenten und zum anderen gegen Unternehmen, die auf das Produkt oder das eigentliche Zielunternehmen und dessen verbreitung finanziell angewiesen sind. Ich führe mit einem Kumpel diese Diskussion schon, seit ich ihn kenne. Und das sind erst 3 Jahre. Haben aber schon unzählige Stunden damit verbracht. Und er will es einfach nicht wahrhaben. Der Beweis dafür aber steckt in unseren Hosentaschen.

Die Konsumenten wollen es einfach und sie wollen es günstig. Und erkennen kann man es an Smartphones. Von der Bedienung her ähneln sich iOS und Android relativ stark. Der einzige Außenseiter, der sich völlig abhebt, ist Microsoft mit Windows 10 Mobile bzw. WP7, WP8 und WP8.1. Damit kommen (aus welchem Grund auch immer) die allermeisten nicht klar und die Teile liegen wie Blei in den Regalen. Ich selbst zum beispiel besitze mein drittes Lumia. Zuerst das 800, dann das 930 und seit kurzem das 950. Und ich bedauere es unendlich, das es wahrscheinlich seitens MS keine neuen Consumer-Telefone geben wird. Aber das schweift schon wieder ab. Android ist das meistgenutzte mobile Betriebssystem und danach kommt mit erheblichen Abstand iOS. Und warum? Smartphones werden mit Tarifverträgen subventioniert und jeder kann theoretisch jedes Smartphone haben und muss dafür kein Vermögen hinblättern. Aber auch bei den normalen Käufern bekommt man sehr günstig brauchbare Smartphones. Allerdings nur mit Android.

Genauso ist es auch bei Computern. Ein Wegfall der Windows-Lizenz wäre preislich kaum zu merken. Wer 500 € aufwärts für ein Notebook hinblättert, dem fallen die paar € für Windows nicht mehr auf. Aber das ist noch nicht der Hauptgrund. Die allermeisten Käufer wollen ein Gerät kaufen, einschalten einen kurzen Einrichtungsassisten in 5 Minuten durchklicken und dann loslegen. Und diese kennen eben nur Windows. Würde man da pauschal ein Linux drauf installieren, dann würde ich locker darauf wetten, das mindestens 98% aller Käufer das Teil wieder zum Händler schleppen und ihn mit dem Stromkabel erhängen.

Wir Gamer sind nur ein relativ kleines Rädchen in der riesigen Welt von Computernutzern. Entscheidend dafür, was Publisher und Entwickler für Betriebsysteme unterstützen, hängen einzig und allein von Marktforschungsergebnissen und somit auch den Marktanteilen einzelner Betriebssysteme ab. Kein Unternehmen arbeitet für Lau. Selbst bei den kleinsten Dingen nicht. Und sie werden zuerst immer die Plattformen unterstützen, wo das meiste Geld zu holen ist. Und das ist laut Marktanteilen mit einem unfassbar riesigen Abstand Windows. Und wenn man sich ansieht, wie abweichend manchmal die Performance bei Spielen zwischen Windows und Linux ist, würde mir da glatt noch ein Grund einfallen.

Über weitere Probleme bzgl. Linux und dem Durchschnittskonsumenten gehe ich an dieser Stelle mal nicht ein. Wenn du Lust hast, können wir da gerne mal drüber diskuttieren. Aber nicht hier

Was gibt es noch wichtiges über diese Thema zu wissen? Eure Erklärungen sind wirklich sehr interessant

Außer, das man sich immer überlegen soll, was man will, was man braucht und ob man sich selbst dazu in der Lage sieht, es umzusetzen, eigentlich nicht viel. Aber vielleicht kann man bei einer etwas spezifischeren Frage noch eine Antwort finden

 

[The_Searcher]

Deine Argumente sind mehr als berechtigt ^^

Linux hat aktuell eine schlechte Verbreitung, was niemand bestreiten kann. Und genau da sollte man ansetzen.

Gaming ist aktuell nur schlecht als recht auf Linux machbar (Leistungseinbußen im Vergleich zu Windows). Und genau in diesem Punkt liegt meine Hoffnung in Vulkan. Vulkan eröffnet einem Entwickler die Möglichkeit neben Windows auch Linux als Gamingplattform "performant" zu unterstützen, im Besten Fall natürlich ohne das er für ein bestimmtes OS zusätzliche Optimierungen durchführen muss.

Das Ziel müsste sein das sich Linux immer mehr Verbreitet und das Image eines Nerd-OS wegbekommt ^^. Der Gaming Bereich könnte dafür ein guter erster Ausgangspunkt sein (zumindest für die Verbreitung, nicht für das Image )

Das Linux ein OS ausschließlich für Profis ist, ist mehr oder minder schon längst Geschichte (zumindest in der Theorie). Ich persönlich nutze in der VM Linux Mint in der Cinnamon Editon, welche von der GUI ziemlich nah an Windows 7 rankommt. Das eigentliche Problem von Linux ist folgender Spruch: Was der Bauer nicht kennt, das frisst er nicht ^^ . Die Leute haben einfach Berührungsängste bzw. haben einfach keinen Bock sich mal 1 Stunde hin zu hocken und sich mit Linux zu befassen. Meine Mutter war übrigens auch skeptisch gegenüber Linux Mint, nachdem ich ihr es aber gezeigt habe war sie überrascht das es vom Aufbau W7 ähnlich ist.

Ich hoffe für die Zukunft das sich die Entwickler von größeren Projekten dafür entscheiden Vulkan eine Chance zu geben. Dies wäre der erste Schritt um Linux als OS für jedermann zu etablieren. Wohlgemerkt wäre dies nur der erste Schritt.

PS: Wir können gerne über PN darüber diskutieren ^^