Engine VS Framework
-
knivil schrieb:
also ein Blatt Papier
Das ist Haarspalterei.
Ich denk, jeder, der schonmal ernsthaft mit OpenGL auf mehreren Plattformen gearbeitet hat, weiß, dass das ein durchaus wesentlicher Aspekt ist. Allein wenn man sich schonmal anschaut, wie man auf verschiedenen Plattformen überhaupt erstmal dazu kommt, dass man OpenGL verwenden kann...natürlich ist der Teil des Code, der nur OpenGL verwendet, zumindest theoretisch portabel, eben weil die API standardisiert ist. OpenGL Code ist also in etwa so portabel wie PNG Files...ich will damit nicht sagen, dass das schlecht ist, ganz und gar nicht, es ist imo einfach ein Fakt, dessen man sich bewusst sein sollte, wenn man plattformübergreifend mit OpenGL arbeiten will...
knivil schrieb:
OpenGL ist eigentlich nichtmal eine Library
Wenn ich mir anschaue, wie ich Shader zu laden habe, dann wuerde ich es schon als Framework einordnen.
Ich versteh nicht ganz, auf was du hinaus willst. Eine klare Grenze zwischen Framework und Library ist eher schwer zu definieren. Eine imo relativ sinnvolle Definition wäre wohl: Ein Framework liefert mir out of the box eine lauffähige Anwendung einer ganz bestimmten Art, deren Verhalten erweitert und angepasst werden kann, während eine Library von selbst erstmal nichts tut. OpenGL ist eine low-level Grafik API und von mir aus eine Library, aber ganz sicher kein Framework...
-
Ich hab mal irgendwo gelesen, dass der Unterschied zwischen einer Lib und einem Framework ist, dass das Framework einen lauffähigen Rahmen bietet, wo man reinprogrammiert (quasi erweitert), während die Bibliothek nur als Zusatz zum eigenen Programm gewertet werden kann. ("Nur" natürlich in Anführungstrichen)
-
OpenGL Code ist also in etwa so portabel wie PNG Files...
Was soll man dazu noch weiteres sagen ...
out of the box eine lauffähige Anwendung
Nein, das verstehe ich nicht unter einem Framework. Windows Media Foundation ist auch ein Framework, aber liefert keine lauffaehige Anwendung von sich heraus. Gleiches gilt fuer viele weitere.
aber ganz sicher kein Framework...
Ja, das sagtest du bereits. Ich weiss auch gar nicht, warum du Library und API ins Boot holst, da sie konzeptionell auf einer anderen Ebene angesiedelt sind.
Die Komponenten in bsp. OpenGl oder Media Foundation kann nur im Kontext von OpenGl (oder MF) benutzen. Laden von Shadern passiert immer gleich und kann von Hand selbst ausgefuehrt werden. Benutzerdefinierter Code in Form von Shadern werden dem OpenGl-Rahmen uebergeben. Gleiches gilt auch fuer andere APIs, die gleichzeitig Frameworks sind, bspw. OpenCl ... Genau das gleiche Ding. Hier werden eben keine Rahmen fuer das Laden von Texturen, Shadern, ... angeboten sondern Mittel und Wege fuer Number crunching auf GPUs (jaja ist nicht beschraenkt auf GPUs, darum geht es aber nicht, is nur nen Beispiel).
Im Gegensatz eine Komponente, bsp. std::thread der Standardbibliothek in C++. std::thread ist semantisch unabhaengig von restlichen Komponenten wie std::vector. std::thread kann auch ohne std::vector herausgeloest benutzt werden.
Die Aussagen "OpenGL ist eine Grafik-API und ein Framework" widersprechen sich nicht.
-
Du kannst Shader z.B. ohne Texturen benutzen, std::thread auch nur im Kontext von C++, deinen benutzerdefinierten Code übergibst du an std::thread im Konstruktor...
-
Du kannst Shader z.B. ohne Texturen benutzen
Darum geht es nicht. Es geht darum, wie OpenGl-Shader auf die Grafikkarte gelangen, wie Texturen auf die Grafikkarte gelangen, wie OpenCl-Daten auf die Grafikkarte gelangen, wie Daten abgeholt werden. Texturen, Shader, OpenCl-Programme selbst ist der "User-Funktionalitaet, sie ist also optional. Das es sich dabei um low-level Sachen handelt, ist Banane. Laden, Senden, Compilieren, Transferieren wird als Rahmen von OpenGl, OpenCl, DirectX, Media Foundation, ... angeboten.
std::thread auch nur im Kontext von C++
Du verstehst einfach nicht.
-
Von mir aus, nach deinem Verständnis ist dann also C++ auch ein Framework!?
knivil schrieb:
std::thread auch nur im Kontext von C++
Du verstehst einfach nicht.
In der Tat, deine Definition von Framework erscheint mir relativ allumfassend. Wir können uns natürlich darauf einigen, dass du unter einem Framework etwas anderes verstehst als ich, dann ist die Diskussion natürlich sinnlos und du hattest per Definition von Anfang an recht...
-
Die Standardbibliothek ist eine Komponentensammlung. Der Teil um Stream und IO ist ein Framework.
dass du unter einem Framework etwas anderes verstehst als ich
Und im Gegenzug kannst du mir natuerlich verraten, warum OpenCl oder Windows Media Foundation Frameworks sind, obwohl sie nicht out-of-the-box eine lauffaehige Anwendung liefern.
-
knivil schrieb:
dass du unter einem Framework etwas anderes verstehst als ich
Und du kannst mir natuerlich verraten, warum OpenCl oder Windows Media Foundation Frameworks sind, obwohl sie nicht out-of-the-box eine lauffaehige Anwendung liefern.
Ich hab niemals gesagt, dass ich OpenCL oder WMF als Frameworks bezeichnen würde. OpenCL ist ebenfalls nur eine API Spezifikation, WMF würde ich als Library oder Komponente sehen.
-
Ich hab niemals gesagt, dass ich OpenCL oder WMF als Frameworks bezeichnen würde.
Schon wieder. Nein, du hast es nicht gesagt, aber andere ... ausser mir. Wenn du natuerlich deine eigene Definition von Framework hast als ... die Macher von Frameworks ... dann sind Missverstaendnisse vorprogrammiert.
OpenCL ist ebenfalls nur eine API Spezifikation
Also Framework fuer die einen und API-Spec fuer dot.
http://www.khronos.org/assets/uploads/developers/library/overview/opencl-overview.pdf 3te Folie unten. Oder http://en.wikipedia.org/wiki/Media_Foundation erster Satz.Zu OpenGL: Framework wird nicht explizit erwaehnt, aber
1.2.3 Our View
We view OpenGL as a pipeline having some programmable stages and some statedriven fixed-function stages that are ...Also eine Pipeline-Model mit fixer Funktionalitaet. Programmierbar durch User-Code ist ebenfalls an ausgewaehlten Stellen moeglich. Klingt sehr nach Framework fuer mich.
Du kannst dir auch die Titelseite von http://www.opengl.org/registry/doc/glspec44.core.pdf ansehen. So sieht ein Framework aus. Zum std::thread: Wahrscheinlich schlecht gewaehltes Beispiel, da mit future/promise, package_task, mutex, ... es eher Framework ist als nur reine Komponente.
Aber gut, dass wir drueber gesprochen haben.
-
FERNman schrieb:
Hey Leute!
Ich und ein freund sind seid 1-2 Monaten am C++ lernen und fragen uns nun, wie man eigentlich dann ein großes Spiel entwickelt. Das heißt nicht, dass wir schon so weit sind, dass sind wir definitiv nicht, aber wir wollen wissen wie man das beginnen würde. Also, würdet ihr eine Engine (CryEngine 4/ UnrealEngine) oder ein Framework empfehlen? Wir wollen kein! 2D Spiel entwickeln, sondern ein 3D Game mit Missionen, Charakterenen usw.
Welche Programme würdet ihr uns zur Entwicklung mit einem Framework empfehlen? Und falls Framework, eher DirectX oder OpenGL?MFG
FERNmanBlender, Gimp, Photoshop, 3ds Max.
-
OpenGL ist ein Blatt Papier? Selten sowas dummes gehört.
-
Danke erstmal für eure vielen Antworten! Ich werde mir das alles zu herzen nehmen. Auch die Diskussion weiter oben finde ich sehr interessant!
MFG
FERNman
-
looooool schrieb:
OpenGL ist ein Blatt Papier? Selten sowas dummes gehört.
Gut, es ist ein pdf, wenn du's genauer haben willst...
-
Genauso sind die IO-Streams kein Framework, sondern ein PDF?
-
pdf schrieb:
Genauso sind die IO-Streams kein Framework, sondern ein PDF?
zomg
spezifikation == pdf
spezifikation != framework
-
Spezifikation == Beschreibung
Spezifikation != Papier
Spezifikation != PDF
