Engine VS Framework



  • Also meine kleine Begriffssammlung zu den Begriffen, welche ich hier verwende:

    -DirectX/Direct3D: Schnittstelle zwischen Hardware und Software, benutzt zur Grafikanzeige, aber auch als Sound oder Eingabegeräte-Unterstützung

    -OpenGL: Ebenfalls eine Schnittstelle zwischen Hardware und Software, aber nur zur Grafik-Darstellung geeignet, Plattform unabhängig. Für Sound wird eine weitere Bibliothek gebraucht.

    -Engine: Ist eigentlich nur ein spezifiziertes Framework, speziell Grafik-Engines sind sehr spezialisiert.

    -Framework: Nur ein Grundgerüst, welches Erweitert und so verändert wird, wie man es haben wird. Kann dafür verwendet werden, um z.B. eingaben auf der Tastatur zu empfangen und bearbeiten.

    Ihr könnt mich gerne ausbessern, falls irgendetwas nicht richtig ist, ich bin kein meister und möchte es nur besser verstehen.

    MFG
    FERNman



  • Wenn es darum geht, mit möglichst wenig aufwand eine gewisse Spielidee umzusetzen, nimm Unity oder das UDK, C++ ist dann sowieso nicht unbedingt eine gute Wahl. Wenn es darum geht, die technischen Hintergründe zu verstehen, lern ordentlich C++ und fang langsam an. Mein Rat wär, sich erstmal SFML zu schnappen und ein bisschen mit 2D rumzuspielen...



  • Danke für die erste wirklich sinnvolle Antwort!

    Ja ich werde sowieso erstmal SMFL lernen, und dann langsam auf 3D umsteigen!

    MFG
    FERNman



  • Ich hatte vorher nur ganz kurz zeit, deswegen konnte ich nicht so ausführlich antworten!
    Aber, ich würde gerne wissen, ob große Studios auch mit Engines arbeiten, oder aber einfach ihre eigenen Frameworks haben?

    MFG
    FERNman



  • Jedes Spiel hat eine Engine. Egal ob groß oder klein.
    Die Frage ist nur, ob man einen Teil des Spiels explizit als Engine entwikclet und so nennt, oder eben nicht.

    Und die Großen verticken ihre Engines auch (UnrealEngine, CryEngine, usw...)

    Frameworks findet man eher im Business-Application Bereich.



  • Du schwärmst schon zu weit, diese Fragen solltest du erst in mind. einem Jahr stellen, gerade machst du dich nur umsonst ungeduldig.

    Große Studios haben viele Angestellte, die bezahlt werden wollen, da kann kaum Zeit für eigene Frameworks investiert werden, meist werden gut entwickelte, kommerzielle Engines gekauft (es sei denn, die derzeitigen bieten nicht gewünschtes und es bestehen Aussichten, die eigene Engine nachher gut verkaufen zu können).
    An einem einigermaßen vernünftigen 3D Spiel sind auch viele fähige Personen mit unterschiedlichen Aufgaben beteiligt (Grafiker, Sound-Designer, Story-Schreiber, Modeler, Programmierer, ...), ihr solltet eure Erwartungen also nicht allzu hoch stecken und noch eine Menge lernen!



  • Eine Spieleengine ist ein Framework. Ob DirectX oder OpenGl als Framework gelten, ist bestreitbar.



  • OpenGL ist eigentlich nichtmal eine Library, sondern eine API Spezifikation, also ein Blatt Papier und ganz sicher kein Framework. Eine OpenGL Implementierung ist dann die Library, die man in der Regel verwenden und diese Implementierung ist auch nicht plattformunabhängig, lediglich das Interface ist standardisiert und daher mehr oder weniger plattformunabhängig (der selbe Code lässt sich mit verschiedenen OpenGL Implementierungen verwenden). Von DirectX sind auch nurmehr einige wenige Komponenten übrig geblieben und die sind mittlerweile alle fixe Systemkomponenten von Windows. Direct3D ist, imo, auf jeden Fall eine API oder von mir aus eine Library, aber ganz sicher kein Framework.



  • also ein Blatt Papier

    Das ist Haarspalterei.

    Direct3D ist, imo, auf jeden Fall eine API

    Jeha ... jedes Framework hat 'ne API.

    alle fixe Systemkomponenten von Windows

    Wo und wie es integriert ist, ist nicht von Belang.

    lediglich das Interface ist standardisiert

    Corba ist auch standardisiert und ist trotzdem ein Framework fuer verteilte Anwendungen.

    Deine ganze Argumentation ... hat nichts mit der Frameworkfrage zu tun.

    OpenGL ist eigentlich nichtmal eine Library

    Wenn ich mir anschaue, wie ich Shader zu laden habe, dann wuerde ich es schon als Framework einordnen.



  • 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
    FERNman

    Blender, Gimp, Photoshop, 3ds Max.



  • OpenGL ist ein Blatt Papier? Selten sowas dummes gehört. 😃


Anmelden zum Antworten