✔ [C++]OpenGl Nehe, GameEngine und noch ein paar Fragen

C

CodeCrafterCpp

Erfahrenes Mitglied
Hallo,
Ihr kennt bestimmt http://nehe.gamedev.net/ und da sind die Codes ja auf OpenGl 3 geschrieben. Kennt ihr eine Tutorial Seite wo es um OpenGl4 geht oder was man ändern muss an den Codes von OpenGl 3 auf 4.

Ist OpenGl eigentlich eine Game Engine?
Ich möchte ja gerne so einen kleine Game Engine schreiben. Mir ist klar das es viel Erfahrung brauch die ich nicht habe aber da mit die Grundlagen zu langweilig sind hab ich mich entschlossen immer zwischen Grundlagen, OpenGl und WinApi zu tauschen.

Also kennt jemand ein OpenGl Tutorial mit Opengl 4.x und am besten eins was nicht Plattform abhängig ist.

Und noch eine Frage. Wie macht man eigentlich so was wie OpenGL. Kann ich so was selber machen also das ich die Farbe von Pixeln selber ändere und somit halt eigene Bibliotheken machen? Vllt hat da auch jemand ein Tutorial oder so was.


mfG
 
Allein die Frage zeigt, dass du sehr weit weg davon bist eine Game Engine zu schreiben.
Es macht kaum Sinn dir das zu erklären, aber weil ich selbst vor einigen Jahren da angefangen habe, wo du heute stehst, versuche ich mal dir meine Erfahrungen in Kurzform zu geben.

Das Allererste was man nie vergessen darf ist, ein PC inkl. aller Programme die darauf laufen macht immer nur genau EINE Sache auf einmal.
Das klingt vielleicht unglaublich, für manche sogar lächerlich, in Zeiten von QuadCore, aber wenn man ganz genau hinschaut ist das eine unerschütterliche Tatsache.
Da werden sicher einige mit "multithreaded" Zeug argumentieren, aber wenn man bedenkt wieviele CriticalSections, Mutexes und Zeug man dazu braucht kann man das vergessen, für die Frage hier ist es eh unwichtig, also lassen wir das einfach mal so stehen, ein PC macht immer nur eine Sache auf einmal.

Windows (oder auch jedes andere Betriebssystem) muss aber Programme im Dutzend gleichzeitig verwalten, vom System samt Treibern über Firewall und Antivirus bis zu allen laufenden Anwendungen.
Darum schaltet Windows zwischen allem was da läuft hin und her, sprich Windows legt immer sämtliche laufenden Programme auf Eis, weist dann genau einem ein bisschen Rechenzeit zu, legt es wieder auf Eis, weist dem nächsten Programm ein bisschen Rechenzeit zu, usw.
Das Ganze im Bereich von Nanosekunden, so dass es fürs menschliche Auge so aussieht, als ob das alles gleichzeitig passiert.
Wenn du von den langweiligen Grundlagen zumindest ein bischen was gesehen hast, kennst du vielleicht den Begriff "Message Cue".

OpenGL (egal in welcher Version) ist eine Grafik Engine, die in die Message Cue eines Programms eingebaut wird.
Vereinfacht gesagt schreibt man einfach eine if() Bedingung in die Message Cue, die jedes Mal wenn das Programm von Windows etwas Rechenzeit bekommt überprüft, ob das Programm diese Rechenzeit überhaupt benötigt, und wenn nicht nutzt man die Zeit um Grafiken zu rendern, Anzeigen zu aktualisieren, usw.
Sinn der Sache ist, dass man so dem Programm selbst den Vorrang geben kann.
Ohne diese Bedingung in der Message Cue würde jeder Grafikbefehl den Rest vom Programm lahmlegen, wodurch alle Funktionen die sehr schnell sein müssen, ins Stottern kommen könnten, aber durch diese Bedingung kann man bei hoher CPU Last einfach ein paar Frames in der Grafik überspringen, während der Rest vom Programm flüssig weiterlaufen kann.
In kurz: Je schneller der PC, desto besser die Grafik, aber auch auf langsameren PC´s läuft das Programm immer noch flüssig, nur halt mit weniger Frames pro Sekunde.

Eine Game Engine ist etwas völlig Anderes, auch wenn sie an derselben Stelle ansetzt.
Auch für eine Game Engine baut man eine Bedingung in die Message Cue ein, nur dass die nicht die Grafik aktualisiert, sondern rechenintensive Funktionen im Programm ausführt.
Als ganz einfaches Beispiel, denk an ein Schachprogramm, was immer dann wenn die Message Cue nichts zu tun hat Züge berechnet.
In kurz, je schneller der PC, desto stärker spielt das Programm, weil es mehr Zeit zur Berechnung hat, aber es spielt auf jedem PC gleich schnell.

Moderne Programme, insbesondere Spiele brauchen beides, eine Grafik Engine UND eine Game Engine, aber wenn da zuviel if() in der Message Cue steht, stottert ein Programm selbst dann, wenn es fast nichts zu tun hat, darum baut man nur eine Bedingung in die Message Cue ein, die immer wenn das Hauptprogramm nichts zu tun hat erstmal prüft wo mehr Bedarf besteht und dann erst entscheidet, ob die verfügbare Rechenkapazität für Grafik oder Berechnungen genutzt werden soll.

Klar kann man sowas selber schreiben, OpenGL und eine Game Engine sind nichts weiter als Programme, nur dass sie so sinnvoll geschrieben sind, dass man sie in andere Programme einbauen kann, sprich du kannst dich auf den Kern deines Programms konzentrieren und dir z.B. den Aufwand das Rendern der Grafik zu coden ersparen.
Um das zu verstehen müsstest du wissen, was Klassen und Schnittstellen sind, aber lassen wir das mal beiseite.
Effektiv ist absolut ALLES was auf dem Bildschirm angezeigt wird ein ganz simples .bmp Format, völlig egal, woher es kommt, völlig egal durch wieviele Berechnungen es gejagt wird, ganz am Ende steht immer ein Bild was ohne jegliche Tricks Pixel für Pixel an den Bildschirm übertragen wird.
WENN du also z.B. weisst, wie man ein .jpg decoded, kannst du dir die Library dazu sparen.
WENN du gut genug bist optimalen Code zu schreiben, mit dem man innerhalb der verfügbaren Rechenkapazitäten 2 - 300 vollständige Bildschirminhalte pro Sekunde rendern kann, brauchst du auch kein OpenGL.
Theoretisch brauchst du nicht mal ein Betriebssystem, wenn du weisst wie die Hardware funktioniert kannst du alles von Grund auf selber schreiben.
Windows inkl. allen Treibern und sonstigen Unterprogrammen ist auch nichts weiter als ein paar Programme die irgendjemand irgendwann mal gecoded hat.
Dumm daran ist nur, selbst WENN du das im Schlaf könntest, wenn du ohne zu überlegen einfach nur den Code eintippen könntest, sagen wir grosszügig, du schaffst 500 Zeichen pro Minute, würde es nur aufgrund des Umfangs für einen einzelnen Programmierer der nicht auf vorgefertigten Code von Anderen zurückgreifen will 1000de Jahre dauern es zu tippen.

Wie schon gesagt, ich habe mal genauso gedacht wie du, aber aus meiner eigenen Erfahrung kann ich dir sagen, der Sprung ins kalte Wasser, learning by doing, dauert am Ende LÄNGER als sich zu Anfang einmal durch die langweiligen Grundlagen zu arbeiten und das Ganze von Anfang an auf solidem Grundwissen aufzubauen.
Ich persönlich code auch lieber selber als auf vorgefertigte Sachen zurückzugreifen, aber das hat seine Grenzen, insbesondere beim Wissen.
Wenn ich entweder 100 Jahre brauchen würde um es zu tippen, oder nicht gut genug bin optimalen Code für eine bestimmte Funktion zu schreiben, bleibt mir keine grosse Wahl.
 
Zuletzt bearbeitet:
@Thomasio: "Message Cue": Du meinst Queue. Ich weiß, unmögliches Wort.

Und das man Ogl selbst schreiben könnte (mit genügend Zeit)...naja.
Wenn man noch eine komplette Halbleiterfabrik im Keller hat :D
OpenGL geht nur, wenn die Hardware mitmacht.
Aber Gameengines kann man natürlich selbst schreiben.


@TO, ergänzend zu Thomasio:
Kurz gefasst ist eine Game Engine also etwas,
was über die Grafik hinaus andere spielrelevante Sachen macht.
Sie kann sich üm Sound kümmern; ermitteln wann man gewonnen hat etc.,
Kollisionserkennung implementieren, ein Netzwerkprotokoll bereitstellen etc.etc.
Grund, wie schon gesagt, damit jeder nicht alles von vorn machen muss
(deswegen gibt es uA. Betriebssysteme.)

"Langweilige" Grundlagen: Nichts für ungut, aber bei einem Projekt
im Größenbereich 3D-Gameengine wird man ohne solides Grundlagenwissen scheitern.
Würde mal behaupten, dazu braucht es sowieso mehr als Grundlagen.

Ogl3/4: Version 4 hat zwar verglichen zu 3 neue Sachen, aber nichts Zentrales weggenommen.
Nehe sollte also weiterhin funktionieren.

Plattformunabhängigkeit: OpenGL ist das schon von selbst
(nur mehrmals kompileiren muss man es für verschiedene Betriebssysteme).
Weil aber ziemlich sicher mehr als OpenGL im Programm gebraucht wird...
weitere Bibliotheken dazunehmen, die bestimmte Sachen für Windows und Linux
gleichzeitig anbieten, und den Rest selbst doppelt schreiben.
So ist das mit C/C++ eben.
Für Tastatur/Maus/Sound/Netzwerk/2D würde zB. SFML für Win+Lin haben,
dazu OpenGL (kann mit SFML sehr gut gekoppelt werden) für 3D...
da hat man schon einiges zusammen.

Pixel-setzen: Wenn du damit bei einem 3D-Programm beginnst, bist du da,
was Thomasio schon als Alles-selbst-machen angesprochen hat.

Das komplette OpenGL ist "nur" dafür da, 3D-Formen (meistens Dreiecke, die irgendwie in der virtuellen "Welt" sind) in Pixel vom Bildschirm umzurechnen.

Unser menschliches Auge braucht eine gewisse Bildanzahl pro Sekunde,
damit es flüssig ausschaut.
Mit Windows/Linux-Bordmitteln kannst die ganzen Pixel nicht schnell genug setzen,
um diese Geschwindigkeit zu erreichen.

Betriebssysteme sollen das auch nicht unbedingt. Das sind Allrounder,
die ziemlich alles irgendwie können sollen. Solange sie Möglichkeiten zum Einbinden von besseren Sachen bieten (Treiber etc.), für speziellere Software -> OpenGL...
Wenn man eine professionelle Bildbearbeitung will, nimmt man auch Photoshop oder sowas her, statt das fix ins Betriebssystem einzubauen. Die Leute, die kein Photoshop wollen, würden sich über den verbrauchten Speicher aufregen...

Also, mit Basismethoden kannst du die Pixel nicht schnell genug zeichen.
Obwohl die Grafikkarte das kann, nur weiß das OS das nicht.
OpenGL weiß es, und aiuch, wie die Grafikkarte dafür "bedient" werden muss.
Selber programmieren? Allein? Viel Spaß, für die nächsten paar Jahrzehnte...

(Anfangen würde ich mit einem Mathematikstudium.
Die Projektionsberechnungen gehen über die durchschnittlichen Schulkenntnisse hinaus.)


PS:
Damit du etwas von der Pixelvorstellung wegkommst:
In OpenGL (und auch DirectX) werden die Dinge eher so aufgebaut
(ist nicht wirklich korrekt, aber viel zutreffender als Pixelmalerei):
http://www.artistsvalley.com/3D-animation/images/human-wireframe.jpg
Alles aus solchen Teilen zusammengesetzt.
Jedes Teil durch seine Kanten beschrieben, in einem dreidim. Koordinatensystem.
 
Achja und zu NeHes Tutorial. Ich habe das auch letzten Monat mal bisschen durchgemacht und ich fand es wirklich gut. Einige Kapitel wurde auch überarbeitet und auf neuerem Stand gesetzt, sodass die alten Funktionen für die Texturen nicht mehr genutzt werden (wird dort auch erklärt). Wenn man das verstanden hat, dann kann man die anderen Kapitel die noch nicht überarbeitet wurden auch sehr leicht ändern.
 
Naja... die NeHe Tutorials sind für den Anfang ganz nett. Aber erfahrungsgemäß sind die meisten Tutorials irgendwann vor dem Core Profile stehn geblieben, was Konzepte usw. anbelangt.

Ich hab mich bis Anfang März gut ein halbes Jahr intensiv damit auseinandergesetzt (Praxis-Semester, Open GL ES usw.) und irgendwie ist der Einstieg da schon ziemlich holprig. Der Learning Modern 3D Graphics Programming Link ist auf den ersten Blick ganz brauchbar, auch wenn das HelloWorld-Beispiel z.B. wieder einige interessante (und fürs Verständnis wichtige Dinge) verheimlicht ;)

Vielleicht schaff ichs, in den nächsten Semesterferien mal die Basics soweit wirklich brauchbar aufzubereiten ;)
 
Um antworten zu können musst du eingeloggt sein.

Neue Beiträge

Zurück