plattformunabhängige Grafikengine
-
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