Grafik Engine

[Tobias1983]

Hallo zusammen,

ich möchte mich mal in Grafikprogrammierung probieren, jedoch möchte ich erstmal wissen wie das ganze funktioniert( also eine Grafikengine ).
Deshalb wollte ich wissen ob mir jemand ein paar gute Informationsquellen nennen kann.
Also bisher habe ich das Buch von Stefan Zerbst über DirectX Programmierung.

Jedoch fehlt mir noch das Verständnis wie eine Engine intern funktioniert.
z.B. ob immer der Komplette Bildscirm gezeichnet wird, oder ob immer nur teile Refresht werden.

Ich würde gerne eine eigene kleine Engine schreiben um mein Verständniss dazu zu verbessern.

Deshalb bin ich über jeden Link / jedes Buch / jede Informationsquelle die jemand nennen kann dankbar.

Vielen dank im vorraus.

Gruß Tobias

[exploid]

...

[Tobias1983]

Hi,

danke für deine Antwort.

Aber jetzt ne frage, wird in diesen Büchern auch erklärt wie eben so was funktioniert.

Gehen wir mal davon aus ich würde ein eigenes Betriebssystem programmieren.
Unter diesem funktioniert kein OpenGL und kein DirectX somit kann ich beides nicht verwenden.
Und müsste etwas komplett eigenes bauen.

Dann hätte ich eben gerne das Wissen wie intern so was arbeitet.
Eben gerade das darstellen ist ja bekanntlich das langsamste.
Wird dann z.B. wenn sich ein Text änedrt nur dieser Text dargestellt oder der ganze Bildschirm.
Und wie wird berechtnet was davon dargestellt werden soll.

Sowas wüsste ich gerne.

Gruß Tobias

[Jörg]

Frueher gern gelesen:

Graphics Programming in C
Zen of Graphics Programming

Ohne DX, OpenGL und den ganzen neumodischen Kram ;)
Dazu noch ein einfaches Buch ueber lineare Algebra und du kannst loslegen...

[Krishty]

Gehen wir mal davon aus ich würde ein eigenes Betriebssystem programmieren.
Unter diesem funktioniert kein OpenGL und kein DirectX somit kann ich beides nicht verwenden.
Und müsste etwas komplett eigenes bauen.

Dein Betriebssystem würde dem Treiber der Grafikkarte sagen, was er auf den Bildschirm zeichnen soll. Wie die Hardware das umsetzt, und dass ein Treiber zur Verfügung steht, ist eine Sache von dessen Hersteller. Es liegt also ganz einfach außerhalb deines Verantwortungsbereichs. Bei GDI war es afaik so, dass jedes angeschlossene Gerät (egal, ob Bildschirm oder Drucker) zumindest die Funktion unterstützen musste, an einer bestimmten Position einen Punkt mit einer bestimmten Farbe auszugeben. Darauf aufbauend konnten von GDI dann Linien gezeichnet werden, schließlich auch Formen und Texte. (Korrigiert mich, wenn ich mich irre).

Wenn es keine Treiber gibt, unterstützt jede Grafikkarte zumindest Default-Modi wie den Textmodus, den du siehst, bevor dein Rechner beim Booten das Betriebssystem startet. (Sonst würde dann ja noch nichts angezeigt werden können.) Wie das genau funktioniert ist schon komplexer, aber vor allem ist es für heutige Programmierung völlig belanglos ;) Selbst, wenn du das entsprechende Wissen hättest, könntest du es nur sehr schwer einsetzen (z.B. indem du einen eigenen Treiber programmierst), weil das Betriebssystem die Hardware vor jedem nicht aus den Annalen erfolgenden Zugriff schützt.

Wird dann z.B. wenn sich ein Text änedrt nur dieser Text dargestellt oder der ganze Bildschirm.
Und wie wird berechtnet was davon dargestellt werden soll.

Auf Windows bis Vista nur die geänderten Elemente, ab Aeroglass alles (weil es auf heutigen GPUs flotter ist und der Bildschirm nicht mehr zumüllt, wenn was hängt). Da jedes Fenster eine Position hat, und jeder Text intern als Fenster gehandhabt wird (wie auch jeder Button und jedes Bild), entspricht die Fläche, die man aktualisiert, der Fensterposition in der linken oberen und Fensterposition + Fenstergröße in der rechten unteren Ecke.

Aber ganz egal, wie du das Pixel-Array, das intern deinen Bildschirm repräsentiert, veränderst – die Hardware behält immer eine Kopie davon, weil der Bildschirm je nach Wiederholrate sowieso 60 bis 120 × pro Sekunde nochmal mit dem kompletten Videoignal beschrieben werden muss.

========

Wie ein Pixel auf dem Bildschirm erscheint hängt also in erster Linie vom Betriebssystem (und dessen API, wie z.B. Direct3D) ab, das den Treibern sagt, was zu rendern ist. Die Treiber schicken Befehle an die Hardware. Die Hardware schickt ein Videosignal an den Monitor.

Was im Betriebssystem geschieht, ist schon zu komplex, um sich anfangs damit zu befassen (User-Mode vs. Kernel-Mode etc.) und ist für 99% der Programme egal. Was im Treiber geschieht, ist zehnmal komplexer und zu 99,99% für eine Anwendung egal. Was in der Hardware geschieht, ist weitere 10× komplexer und für 99,9999% der Anwendungen egal.

Wenn du also nicht auf 20 Jahre alter Hardware ohne Betriebssystem programmierst oder deine Anwendung die eine, missionskritische Anwendung aus einer Million werden wird, ist es Zeitverschwendung, sich mit sowas zu befassen. Nicht nur, weil es von Betriebssystem zu Betriebssystem, von Treiberversion zu Treiberversion und von GPU-Modell zu GPU-Modell unterschiedlich ist, sondern weil du daraus nichts über gutes Programm-Design lernst. Einen groben Eindruck zu haben, wie sowas vonstatten geht, ist natürlich nie verkehrt (sonst hätte ich das ja auch nicht geschrieben :) ) und das Wissen um die ungefähre Arbeitsweise der GPU wird bei Optimierungen sehr nützlich – aber solange du noch nichts zum Darstellen hast, nützt dir das alles nichts.

Gruß, Ky

[Aramis]

Hoi,

ich gehe davon aus, dass es dein Ziel ist 3D-, nicht 2D-, Grafik darzustellen.

Gehen wir mal davon aus ich würde ein eigenes Betriebssystem programmieren.
Unter diesem funktioniert kein OpenGL und kein DirectX somit kann ich beides nicht verwenden.
Und müsste etwas komplett eigenes bauen.

Prinzipiell kannst du auch einfach ein Fenster öffnen, und die 3D-Grafik selber berechnen, das berechnete Bild dann am Ende ausgeben.

Dann hätte ich eben gerne das Wissen wie intern so was arbeitet.
Eben gerade das darstellen ist ja bekanntlich das langsamste.
Wird dann z.B. wenn sich ein Text änedrt nur dieser Text dargestellt oder der ganze Bildschirm.
Und wie wird berechtnet was davon dargestellt werden soll.

Eigentlich wird bei der Darstellung von 3D-Grafik immer der ganze Bildschirminhalt einmal pro Frame neu berechnet. Der schematische Programmablauf sieht also ungefähr wie folgt aus:

Code: Alles auswählen

Initialisierung

Solange Programm läuft
    Bildschirminhalt löschen
    Neu zeichnen

3D-Grafik beruht auf gewissen mathematischen Grundlagen, die du dir beibringen musst. Ohne geht es nicht. Direct3D und OpenGL stellen nur Schnittstellen dar, die für viele der anfallenden Berechnungen Hardwarebeschleunigung durch die Grafikkarte bereitstellen.

Eine Grafikengine hat aber meist nur auf unterster Ebene mit dem Grafik-API oder dem Absetzen von Zeichenaufrufen zu tun. Die wichtigste Komponente ist die Szenenverwaltung, d.h. meist eine Baumstruktur, die die gesamte darzustellende Szene hierarchisch ordnet, die sichtbaren Bereiche identifiziert und diese einmal pro Frame in eine Liste von Zeichenaufrufen umwandelt .. diese werden dann an das darunter liegende Grafik-API übergeben.

Deine Frage ist leider relativ wenig konkret, um aussagekräftigere Antworten zu bekommen.

- Alex

[Tobias1983]

Hi,

vielen dank für all euere Antworten.

Also ich versuche mal ein wenig genauer zu beschreiben was ich machen möchte.
Ich programmiere ein ARM Prozessor mit meinem kleinen selbst gebauten Betriebssystem.

Ich habe ein kleines Windowhandling aufgebaut was nicht gerade schnell ist =).
Bzw. verhältnissmäßig "Schnell". Fenster wegnehmen / Fenster wieder hinzu... usw.

jetzt würde ich gerne eine etwas schnellere Grafikausgabe bauen.

Deshalb wollte ich wissen wie das andere machen. und eben ohne DirectX und ohne OpenGL das habe ich da eifnach nicht.

Gruß Tobias

[Jörg]

Na dann sind meine Buchempfehlungen ja doch was wert. Wenn du dich naemlich selber um die Darstellung kuemmern willst, helfen dir die High-Level APIs erstmal nicht weiter.
Schau dich im Nety am besten nach aelteren Artikeln ueber Software-Rendering um, auch aus der Demoszene gibts da die eine oder andere Perle mit Code-Beispielen. Das HUGI-Diskmag ist auch empfehlenswert, zumindest war es das vor einigen Jahren.

Aber nur um sicherzugehen: Welchen Prozessor verwendest Du genau? Hoffentlich nicht einen, der nen integrierten 3D-Kern besitzt? ;)

[FredK]

Ich empfehle dir folgendes Buch:
http://www.amazon.de/3D-Grafik-Programm ... 106&sr=1-1

3D-Grafik Programmierung
von Marius Apetri

[DeRaaZuul]

Ich kann dir das Buch von Stefan "Direct3D and 3D Engine Programming" empfehlen.Es ist sehr gut für Einsteiger ,deckt aber sehr viele Themen ab und ich finde es ließt sich sehr gut.Es gibt viele Bücher die zwar sehr informativ sind aber nach 100 Seiten höre ich meistens auf zu lesen , weil sie sehr träge/zäh geschrieben sind.Hier ist das nicht der Fall.Der Programmier-Still ist in vergleich zu den alten Büchern auch aller erste Sahne :-P

[odenter]

Du willst also ein 2D Gui bauen?
Dann dürften die von Jörg genannten Bücher interessant sein, guter Beispielcode wäre der von XOrg.

[Tobias1983]

Hey,

vielen dank an alle die hier Ihre Tipps abgegeben haben.

Jetzt habe ich erstmal einige Anlaufstellen.

Gruß Tobias