We need a device

We need a device now that we know what type of system we're dealing with. It's important to note that the device should not be confused with the adapter. The adapter represents the graphics card itself, while the device is responsible for rendering, shader programming, resource management, and context handling.

Programming this part of the engine is not particularly challenging since the main work has already been done in the CInterface class. However, there's still a certain logic in this code. The CDevice class is divided into two parts, splitting the functionality into two separate entities: the CDevice class and the DEVICEMANAGER structure.

Why did I structure it this way? Well, I found it more organized for myself. The DEVICEMANAGER part is responsible for managing and monitoring the available graphics devices. It provides access to information about the supported DirectX formats, versions, and feature levels of the devices. The DEVICEMANAGER offers functions to check if a specific format is supported by a particular adapter, retrieve supported formats, DirectX versions, and the total number of adapters. This separation allows for a clear distinction of tasks: the DEVICEMANAGER handles the configuration and monitoring of available hardware without dealing with concrete DirectX operations.

The CDevice class represents a single DirectX device and is responsible for initializing, managing, and using this device. It contains functions for creating and managing DirectX resources such as the device itself, the swap chain, render targets, and depth/stencil buffers. The CDevice class focuses on the specific processes and operations related to DirectX programming, such as creating objects responsible for rendering operations.

There's also a simpler way. If you have specific graphics requirements, such as a particular resolution or graphics settings, you could query the appropriate adapter in the system and then create a device that meets those requirements. This provides greater control over the graphics configuration and can help optimize the performance and quality of graphics in an application.

However, it's often convenient to simply create a device through the engine since the engine manages configurations by default and automatically selects the default setup if nothing is specified. This is especially useful if you don't want to deal with the details of graphics configuration.

Some may now wonder if all the preparatory work was in vain. The preparatory work of selecting a specific adapter in the system and configuring a device with specific settings is not necessarily in vain, even if you ultimately create a standard device through the engine.

The preparatory work of selecting a specific adapter and configuring a device accordingly can be useful for several reasons. Firstly, it allows for fine-tuning of performance. By selecting a specific adapter and configuring specific settings, you can optimize the performance of the application and ensure it runs smoothly without wasting resources.

Furthermore, customization to specific hardware is an important aspect. Sometimes, certain hardware configurations require special settings or optimizations to achieve the best performance. Through preparatory work, you can ensure that the application works well on a variety of hardware configurations and maximizes performance.

There may also be cases where specific graphics requirements go beyond standard configurations. In such situations, it's necessary to manually adjust the graphics settings to meet these requirements.

Lastly, manual configuration of a device allows for the assurance of feature availability. This ensures that certain features or extensions are available and can be utilized when needed.

Wir brauchen ein Device

Jetzt, da wir wissen, welcher Art von System wir gegenüberstehen, benötigen wir ein Gerät (Device), um auf die Grafikhardware zuzugreifen. Das Device sollte nicht mit dem Adapter verwechselt werden. Der Adapter ist die Grafikkarte selbst, während das Device für das Rendering, die Shader-Programmierung, die Ressourcenverwaltung und die Kontextverwaltung zuständig ist.

Die Programmierung dieses Teils der Engine ist im Grunde genommen nicht sehr aufwendig, da die Hauptarbeit bereits in der CInterface-Klasse geleistet wurde. Dennoch gibt es eine gewisse Logik auch in diesem Code. Die CDevice-Klasse besteht aus zwei Teilen, die Funktionalität wird in zwei separate Teile aufgeteilt: die CDevice-Klasse und die DEVICEMANAGER-Struktur.

Warum habe ich das so gemacht? Nun, ich fand die Struktur so für mich übersichtlicher. Der DEVICEMANAGER-Teil ist für die Verwaltung und Überwachung der verfügbaren Grafikgeräte zuständig. Er ermöglicht den Zugriff auf Informationen über die unterstützten DirectX-Formate, -Versionen und -Ebenen der Geräte. Der DEVICEMANAGER bietet Funktionen zum Überprüfen, ob ein bestimmtes Format von einem bestimmten Adapter unterstützt wird, zum Abrufen unterstützter Formate, DirectX-Versionen und der Gesamtanzahl von Adaptern. Diese Trennung ermöglicht eine klare Abgrenzung der Aufgaben: Der DEVICEMANAGER kümmert sich um die Konfiguration und Überwachung der verfügbaren Hardware, ohne sich um konkrete DirectX-Operationen zu kümmern.

Die CDevice-Klasse repräsentiert ein einzelnes DirectX-Gerät und ist für die Initialisierung, Verwaltung und Verwendung dieses Geräts verantwortlich. Sie enthält Funktionen zum Erstellen und Verwalten von DirectX-Ressourcen wie dem Gerät selbst, der Swap Chain, Render Targets und Tiefen-/Stencil-Puffer. Die CDevice-Klasse konzentriert sich auf die spezifischen Abläufe und Vorgänge im Zusammenhang mit der DirectX-Programmierung, wie z. B. das Erstellen von Objekten, die für Rendervorgänge verantwortlich sind.  

Es geht auch einfacher

Wenn man spezifische Anforderungen an die Grafik hat, wie zum Beispiel eine bestimmte Auflösung oder Grafikeinstellungen, könnte man den passenden Adapter im System abfragen und dann ein Device erstellen, das diese Anforderungen erfüllt. Dies bietet eine höhere Kontrolle über die Grafikkonfiguration und kann dazu beitragen, die Leistung und Qualität der Grafik in einer Anwendung zu optimieren.

Allerdings ist es oft auch praktisch, einfach über die Engine ein Device zu erstellen, da die Engine die Konfigurationen standardmäßig verwaltet und automatisch, wenn man nichts angibt, das Standardsetup auswählt. Dies ist besonders nützlich, wenn man sich nicht mit den Details der Grafikkonfiguration auseinandersetzen möchte.

Der eine oder andere mag jetzt fragen ob die ganze Vorarbeit umsonst war. Die Vorarbeit, einen passenden Adapter im System zu suchen und ein Device mit spezifischen Konfigurationen zu erstellen, ist nicht unbedingt umsonst, auch wenn man letztendlich über die Engine ein Standard-Device erstellt.

Die Vorarbeit, einen spezifischen Adapter auszuwählen und ein Device entsprechend zu konfigurieren, kann aus mehreren Gründen sinnvoll sein. Zunächst ermöglicht sie eine Feinabstimmung der Leistung. Indem man einen bestimmten Adapter auswählt und spezifische Einstellungen konfiguriert, kann man die Leistung der Anwendung optimieren und sicherstellen, dass sie reibungslos läuft, ohne Ressourcen zu verschwenden.

Des Weiteren ist die Anpassung an bestimmte Hardware ein wichtiger Aspekt. Manchmal benötigen bestimmte Hardwarekonfigurationen spezielle Einstellungen oder Optimierungen, um die bestmögliche Leistung zu erzielen. Durch die Vorarbeit kann man sicherstellen, dass die Anwendung auf einer Vielzahl von Hardwarekonfigurationen gut funktioniert und die Leistung maximiert wird.

Es kann auch Fälle geben, in denen spezifische Anforderungen an die Grafik gestellt werden, die über die Standardkonfigurationen hinausgehen. In solchen Situationen ist es notwendig, die Grafikeinstellungen manuell anzupassen, um diese Anforderungen zu erfüllen.

Zuletzt ermöglicht die manuelle Konfiguration eines Devices die Sicherstellung der Verfügbarkeit von Funktionen. Dadurch kann sichergestellt werden, dass bestimmte Funktionen oder Erweiterungen verfügbar sind und genutzt werden können, wenn sie benötigt werden.