plattformunabhängige Grafikengine
-
Hallo,
ich schreibe nochmal hier ins Forum, weil ich immer noch Leute suche, die Lust haben, mit mir eine Grafikengine zu schreiben, die sowohl plattformunabhängig als auch API-unabhängig ist. Die Engine soll COM- Schnittstellen bereitstellen (für GUI's, für Renderpiblines, für Netzwerk, für Sound und für Inputkklassen).
Gruß Para
-
Was soll deine Engine denn von anderen plattformunabhängigen Engines abheben?
-
Hmmm eine gute Frage....
Also zunächst einmal soll die Engine höchstwahrscheinlich anders als Ogre oder Cube OpenSource werden. Ein großer Vorteil soll sein, dass durch die COM - Objekte es sehr leicht möglich sein wird, Komponenten der Engine leicht zu aktualiseren, und zwar über ein Webportal.
Wenn also später ein Spiel programmiert wird, wird es leicht sein, die Komponenten der Engine durch neuere zu ersetzten, ohne gleich ganze Klassen neu coden zu müssen.
Weiterhin habe ich vor, die Engine so flexibel wie möglich zu halten, sie soll also eine große Anzahl an Dateitypen für Texturen, Models, terrains usw. definieren. Eventuell soll auch ein eigenes Dateiformat entstehen.
Über die Vorteile gegenüber anderen Render Engines bin ich mir noch nicht so klar, allerdings ist das auch ein gutes Diskussionsthema.
Gruß Para
-
Parapiler schrieb:
Ein großer Vorteil soll sein, dass durch die COM - Objekte es sehr leicht möglich sein wird, Komponenten der Engine leicht zu aktualiseren, und zwar über ein Webportal.
gah?
COM ist nicht platformunabhängig, sondern ein microsofterzeugnis. es gibt aehnliches unter linux, aber da ist es nicht so einfach bs unabhängig zu programmieren, wie mit sockets. aktualisierung: was is das fuer eine engine, die alle 4 tage upgedated wird? so ein dings ist einmal fertig, und dann kommen ab und an neue versionen von raus. die muss ich doch nicht ueber ein webinterface updaten 0o. desweiteren sehe ich keine anwendung von com, ausser dass es deutlich langsamer ist als "normal" (auf grafikanforderungen bezogen).sorry, aber es fällt kaum unter "sinnvoll" und noch weniger unter "realisierbar". (werde das noch kurz beobachten und dann schliessen)
-
hmmm wie du sagtest....
In Linux gibt es ähnliche Konzepte. Was du meinst ist, dass eine Dll unter Linux nicht benutzt werden kann. Das ist richtig. Es gibt aber dort auch dynamische Bibliotheken, mit denen dies möglich ist.
Meine Meinung: dieses Problem ist unter Kontrolle zu bekommen.
Zu dem Update-System:
Eine Software ist nie perfekt. Eins ist klar: Für eine Engine gibt es 2 Möglichkeiten. Entweder man erstellt eigenhändig eine Renderpipeline, oder man nutzt OpenGL & Direct3D. Ich halte die zweite Möglichkeit für die sinnvollere. Das Direct3D betrifft, kommt jedes halbe Jahr eine neue Version mit einer neuen Funktionalität raus. Hier wäre es sinnvoll, das COM- Prinzip einzusetzen, um die neuen Funktionalitäten einfach im Spiel einsetzen zu können (und wenn es sich nur um schnelleren Zugriff auf Devices, Texturen, usw.) handelt.
Was OpenGL angeht liegt es etwas anders: Da OpenGL ein anderes Konzept hat und nicht regelmäßig geupdatet wird, hat das Prinzip hier nicht ganz so viel Sinn. Allerdings wird es auch immer wieder in OpenGL Erneuerungen geben, die dann schnell eingebaut werden können.
Und jetzt bitte eine Bitte: Begründe bitte mal warum das nicht realisierbar sein soll? Über sinnvoll lass ich mit mir reden: Es gibt schon genug plattformunabhängige Grafikengines, die allerdings OpenSource sind. Allerdings kenne ich keine, die so ein Pluginkonzept aufbaut.
Gruß Para
-
ok, dann lass ich mir mal was einfallen, aber davor noch was zu com. hast du dich schon mal damit befasst? das problem dabei sind die übergänge von einem comobjekt zum anderen. das geht nicht so hübsch, wie wenn du dlls lädst. drum würd ich dir eher zu dynamischen libs (dll / .so) raten. die kann man leichter updaten, muss man nicht umständlich ins system integrieren, sind schnell wie "fest gecodetes", und in der handhabung um vieles einfacher.
warum ist es nicht realisierbar? da spielen mehrere faktoren ein. das erste ist schon mal, dass es wahrscheinlich keine nutzer für deine lib gibt. es gibt schon einige kostenfreie leistungstarke und portable 3d engines, die ausfürhlich dokumentiert sind. du bist allein, vielleicht mal zu 2. oder auch mehr. allein um eine solche doku zu schreiben, würdest du wochen brauchen. überleg dir mal, was alles reinspielt, um so eine engine zu entwickeln.
design: du musst dir ein gutes konzept überlegen, wie du die engine aufbauen willst, um sie später in der anwendung komfortabel nutzen zu können. sowie was sie alles können soll (dateiformate, input/output, partikel etc etc) (2 wochen tägliche arbeit)
konzept: aus dem design musst du eine struktur, wie die engine programmtechnisch aufgebaut sein soll. ein kompletter entwurf, eine spezifikation der software. (2-3 wochen mindestens)
programmierung: jetz muss der ganze mist programmiert werden. hierbei hast du das problem, dass es jetzt auch auf performace ankommt. sprich: du musst zum einen erstmal die mathematischen grundlagen für gängige operationen (drehn, spiegeln, bewegen von models, licht usw) dann nicht zu unterschätzen die optimierung (mathematische verfahren). da steckt viel drin. frag mal rapso wie lang er für seine engine wie sie heute ist gebraucht hat. (nochmal mindestens 8-10 wochen).summa summarum macht das bei mir im gesamtaufwand >14 wochen, wobei ich jeweils etwa 6-8 stunden arbeit pro tag denke. jetzt musst du mal überlegen, was für faktoren jetzt noch (evtl) stören:
- in manchen bereichen mangelndes programmierwissen (unterstell ich jetzt einfach mal, das hätten wahrscheinlich 95% hier, mich eingeschlossen)
- möglicherweise nicht ausreichende mathematische grundlagen
- mangelndes durchhaltevermögen (10 wochen arbeiten, bis man ein ergebnis sieht? das ist hart)
- nach 4 wochen hast du eine andere idee oder schulstress etc und nicht mehr so viel zeit wie du gern möchtest.sind das einleuchtende erläuterungen zum thema "nicht realisierbar"?
edit: zum pluginkonzept: kA was du dir drunter vorstellst. wenn du damit meinst, dass die engine "teilbereiche" hat, die man laden kann oder nicht (z.b. audio, input, ...) dann glaub ich haben das alles. ich sehe keinen gewinn, wenn ich wählen kann "nehm ich shader x1 oder shader x2", wenn shader x2 eindeutig besser ist? nochdazu kannst du sowas easy über dlls machen
-
Parapiler: Kanns sein dass Dir grundlegendes Verständnis für COM und Co fehlt?
Warum willst Du denn für was betriebssystemunabhängiges auf COM setzen?(Warum willst Du überhaupt COM einsetzen?
Das wird doch nicht mal von MS selbst mehr wirklich verwendet...)
-
ich sehe in noch einer protablen engine eigentlich keinen bis wenig sinnd, da es bereits genug gibt, die vor allem auch (mehr oder weniger) ausgereift sind (ich denke da besonders an SDL) noch eine lib zu basteln (die dann eh niemand nutzt wie schon angesprochen wurde) ist daher unnötig. wenn du grafik programmieren willst, dann bastel doch lieber ein kleines spiel (natürlich mit einer portablen lib dahinter) oder tool aber ich denke der aufwand den solch eine lib macht, ist in anbetracht der schon fertigen libs unnötig
-
Ganz anderes wäre mal die Frage in wie Weit sich der Threadstarter überhaupt mit Grafik-Engines auskennt...
Hast du sowas schonmal gemacht? Schon Erfahrnungen damit gemacht?
Das was du nennst und vorhast klingt sehr aufwendig und kompliziert.
Und wäre meines erachtens nicht realisierbar, sofern man sich nicht schon recht gut damit auskennt.
-
fallen schrieb:
...da es bereits genug gibt, die vor allem auch (mehr oder weniger) ausgereift sind (ich denke da besonders an SDL)...
vorsicht: grafiklib != engine. eine engine stellt unter anderem einen wrapper zu einer oder mehreren grafiklibs zur verfügung. aber com solltest du dir erstmal anschauen, bevor du es einsetzen willst.
-
Korbinian schrieb:
vorsicht: grafiklib != engine. eine engine stellt unter anderem einen wrapper zu einer oder mehreren grafiklibs zur verfügung. aber com solltest du dir erstmal anschauen, bevor du es einsetzen willst.
ups
der beitrag lässt sich aber sicherlich auch auf engines ummünzen
-
Also zunächst mal zu der Sache mit COM:
COM meint im Usrsprung erstmal gar nix Microsoftspezifisches, sondern ist einfach nur eine technische Spezifikation für das Prinzip des dynamischen Ladens von Plugins, also Dll's die Klassen bereitstellen, die von einer abstrakten Basisklasse erben. Von daher wird es nötig sein, für jedes Modul eine Dll / so - Datei und eine Lib/.a Datei zu erzeugen, wobei die Lib die abstrakte Basisklasse und eine Klasse zum Laden der Dll mitbringt (das Laden wird dann wahrscheinlich durch eine Methode realisiert werden, die z.B. einen Pointer auf die Grafikpipeline übergeben bekommt).
Grundsätzlich wurde es schon angesprochen: Die SDL zum Beispiel ist keine Engine, sondern nur ein GUI - Toolkit, welches sich in diesem Fall auf die Erstellung von Grafikfenstern beschränkt. Ich habe vor eine Reihe dieser Toolkits zu kapseln (nur das nötigste). Ich denke da nicht nur an die SDL, sondern auch an GLUT, QT und QTK.
Ich habe jetzt sicher jede Menge vergessen, aber ich kann ja noch Beiträge nachschieben.
Gruß Para
-
Hast du denn selbst schonmal eine Grafikengine oder ähnliches geschrieben?
Oder wie kommst du da drauf sowas zu machen, geschweige denn das du sowas umsetzen kannst?
Nicht persöhnlich gemeint, aber es gehört wohl doch schon ein bissl know-how dazu oder nit?
-
natürlich ist COM primär ein konzept (component object model), aber es ist nunmal so, dass das com nur von microsoft aufgenommen und in windows integriert worden ist (nah verwandt damit auch die activeX sachen). hast du schon mal mit com programmiert? ich arbeite momentan mit dcom (distributed com). es ist einfach nervig, den übergang von einem comobjekt ins andere zu machen (IDispatch lässt grüßen). ich finde, du solltest dir nochmal gründlich überlegen, ob du com für deine engine einsetzen willst, oder ob du nicht schlichtweg zu normalen dynamischen libs übergehst (was dann auch portabler ist).
hast du schon mal mit com programmiert? (bitte beantworte das mal, sonst is die diskussion über com ja/nein hinfällig)soso, du willst also für deine engine gleich mehrere grafikschnittstellen anbieten: SDL, OGL, DirectX, QT, GTK, ...
is dir aufgefallen, dass QT und GTK(+) bereits toolkits sind (sowas wie VCL oder MFC), und eigentlich für anwendungsdesign geschrieben worden sind? das _sind_ schon toolkits. da einen wrapper für zu schreiben is ja eigentlich fu
erstmal über das zeugs informieren.
SDL, OGL und DirectX. da hast dir immer noch sauviel vorgenommen. sei mal ehrlich: wo ist der unterschied zu "ich baue jetzt ein neues betriebsyystem. modular, komplett in c++, super einfaches erweitern durch modularität, integrierter interpreter für c, c++, java, pascal. die grafkoberfläche ist natprlich auhc drin."
lass dir das mal durch den kopf gehn. das ist alleine nicht machbar. (hint: überleg mal, wie viele leute an opengl hinprogrammiert haben, und wie lange!)es ist ja in ordnung hochtrabende pläne zu haben. aber in gewisser weise sollten sie schon realisierbar sein. wäre sie wahrscheinlich, wenn du crack in c++, opengl, directx, etc wärest. aber da würd ich bitte gern mal ein beispiel sehn. was hast du bis jetzt programmiert? schau dir mal an, wie groß die libs von opengl sind. dann überleg mal, wieviel zeilen code es braucht, um auf die größe zu kommen. buh!
ich zerstör ungern illusionen, aber überleg dir vielleicht was kleineres. einen kleinen opengl wrapper z.b. oder einfach mal directx programmieren. mal erfahrungen sammeln.
-
Daraus wird doch eh nichts. Wenn da jemand ne Grafikengine programmieren will und dann was von Netzwerk und Sound faselt sieht man doch gleich, dass das in die Hose geht.
-
Korbinian schrieb:
das ist alleine nicht machbar.
*rumhüpf* hier hier, bei mir läuft das aber
... auch wenn ich nicht sowas tolles wie renderware hinbekomme (da arbeiten wohl mehr als 100leute hauptberuflich dran)Korbinian schrieb:
es ist ja in ordnung hochtrabende pläne zu haben. aber in gewisser weise sollten sie schon realisierbar sein. wäre sie wahrscheinlich, wenn du crack in c++, opengl, directx, etc wärest. aber da würd ich bitte gern mal ein beispiel sehn. was hast du bis jetzt programmiert?
@Parapiler
ja, ich würde auch gerne sehen was für projekte du bisher abgeschlossen hast. Sich so ein grosses Projekt vornehmen ist ja nicht schwer, und grob die theorie darüber zu kennen ist wirklich kein grund anzunehmen dass du dem Projekt gewachsen bist, deswegen her mit den Referenzen, damit wir dir mit unseren Vorurteilen nicht unrecht tun.
Ich würde auch gerne genau den umfang wissen. Du schriebst du willst ne Graphikengine machen, aber dann zählst du noch weitere komponenten auf. Was genau soll die engine am ende können.
Und da an heutigen engines die Tools die benutzt werden für die meißten (die die engine benutzen) wohl wichtiger sind als die graphische Qualität, würde ich gerne wissen welche tools du supporten möchtest, welche von der Engine selbst kommen sollen, wie der Workflow in bezug auf das Datenhandling ist.Wie portabel soll die engine sein? nur zwischen zwei betriebssystemen? oder auch auf verschiedenen hardware platformen (MAC?) oder sogar Konsolen?
naja, ich löcher dich gerne weiter sobald du geantwortet hast
rapso->greets();
-
rapso schrieb:
*rumhüpf* hier hier, bei mir läuft das aber
...i know
aber du hast auch etwas mehr erfahrung mit den sachen, und ma nkann bei dir schon ergebnisse sehen