Implementier doch beide zusätzlich, je mehr Auswahl man später hat, desto besser.

Nein und du brauchst auch nicht das SDK, nimm SharpDX dafür.

Jumpee Rabbit - Jazz Jackrabbit?

wenn du deine Engine gescheit programmiert hast, dann dürfte die Abstrakt genug sein um beides relativ einfach zu implementieren. Dürfte dann eigt. nicht allzu viel Aufwand sein, da man idr für die Architektur bei soetwas am längsten brauchen sollte. Aber einfacher wird vmtl. fürn Anfang DirectX sein, da DirectX etwas mehr als nur eine Grafikkartenschnittstelle ist.

Leider hat der gute TE keine Ahnung von Architektur.

Andy16823 schrieb:

DirectX SDK Downloade, muss dann jdeder der das Spiel spielen will sich auch das SDK Downloaden

Hallelujah! Hast du etwa verpasst, dass sich directX in drölf Verschiedenen Versionen bereits auf jedem Windows-Rechner befindet? Noch nie irgendwelche Spiele Installiert, und dabei mal auf die CD-Hülle geschaut?

Die einzige Entscheidung die man zwischen DX und OGL zu treffen hat, ist die portabilität. Genügt es dir auf Windows-rechnern zu sein -> DX. Willst du auch auf anderen Plattformen sein -> OGL kannst du beides Implementieren ->DX&OGL (DX für Win, OGL für Rest)

EaranMaleasi schrieb:

Die einzige Entscheidung die man zwischen DX und OGL zu treffen hat

Naja. Muss schon sagen, dass mir DirectX eigentlich schon wesentlich sympathischer ist als OGL. Zwar ist OGL nicht an Windows gebunden, was natürlich ein Vorteil ist, jedoch finde ich das zum Programmieren selbst ein Albtraum. Alles ausschließlich über Funktionen mit Handles etc. zu machen. Naja...

Immer noch besser als COM Es gibt bestimmt auch zu OGL einen gescheiten Wrapper.

Es wird schon nen Grund geben, warum ich DirectX inzwischen kann, OpenGL aber nicht (hab mir beides angeschaut). Außerdem ist Platformunabhängigkeit hier kein wirkliches Argument, denn unter Linux muss OGL trotzdem anders angesprochen werden, als unter Windows.

Artentus schrieb:

denn unter Linux muss OGL trotzdem anders angesprochen werden, als unter Windows.

Ich vermute aber mal ganz stark, dass man mit DX auf Linux nicht wirklich weit kommt

Mit .Net auch nicht ohne Pfusch. Auf Plattformunabhngigkeit würde ich hier garnicht achten. .Net ist für Windows konzipiert, dann soll die Engine das auch sein.

Gonger96 schrieb:

Immer noch besser als COM

Wohl kaum.

Doch. Ich halte COM für den letzten Dreck. Funktionen & Handles klingt klasse zum Wrappen. Damit kann man schöne Architekturen hinbekommen (GDI+ z.B.). Bei COM hat man da extrem Arbeit (k.A. wie das in .Net läuft, da ist aber sowieso schon ein guter Wrapper da). Bei Direct2D ist die Doku unvollständig und wichtige Teile fehlen einfach.

EaranMaleasi schrieb:

Hallelujah! Hast du etwa verpasst, dass sich directX in drölf Verschiedenen Versionen bereits auf jedem Windows-Rechner befindet? Noch nie irgendwelche Spiele Installiert, und dabei mal auf die CD-Hülle geschaut?

Und du auch, denn wir sind hier bei .Net, also muss man die Wrapper-Dlls mitliefern, bei Verwendung des DirectX SDKs muss somit das Redistributable installiert werden, welches nicht grundsätzlich installiert wird.

Artentus schrieb:

denn unter Linux muss OGL trotzdem anders angesprochen werden, als unter Windows.

Du meinst beim arbeiten mit Fenstern? Das hat nix mit OGL zu tun.

Außerdem gibt es noch andere Gründe als nur portabilität. OGL ist DirectX performance technisch anscheinend bei vielen Sachen immernoch überlegen(weshalb es auch schwieriger ist, da es 1000 Wege gibt etwas zu implementieren, bei DirectX wirst du auf einen Weg getrimmt, was vieles vereinfacht, aber auch Optimierungen oftmals ausschließt). Außerdem kann man mit OGL Extensions oft Dinge verwenden, die dann bei DirectX 5 Jahre später erst kommen...

Du willst mir sagen, dass der ganze Mist mit zig C-Funktionen, handles und kp was für nen Rotz besser ist wie ein halbwegs objekt orientiertes Modell? Habe mit COM recht gute Erfahrungen gemacht. In .NET lässt sich das importieren, jedoch ist da C++/CLI sicherlich von Vorteil. Ob man eine Technologie anhand dem Vorhandensein einer Dokumentation bei einem Anwendungsfall der besagten Technologie beurteilen kann... ääääuuußerst fragwürdig.

Tatsache ist, dass du mit COM wenigstens halbwegs soetwas wie OOP mitrein bringst, wovon du bei einer beschissenen Architektur wie sie OGL besitzt nur träumen kannst. Was die Funktionalität angeht... tja... da will ich keine Aussage treffen. Da kenne ich mich zu wenig aus.

Eines muss man sagen, C-Style-Programmierung ist in jedem Fall schneller als C++-Style-Programmierung (kann sogar bis zu 50% ausmachen). Allerdings ist die Frage, ob man diesen Tradeof eingehen möchte, Mit DirectX bekomm ich auf meiner Könnensstufe immer noch tausende FPS, da brauch ich nichts schnelleres.

@thefiloe @Artentus ich habe nur von Performance und Funktionalität gesprochen.

Wenn es um den Aufbau geht, dann kann man die beiden nicht vergleichen, da OGL eine reine Grafikkartenschnittstelle ist, wenn da groß OOP wäre, dann wäre was falsch. Außerdem ist für mich das was du mit C Funktionen als Mist bezeichnest nicht nur ein Nachteil. Es hat auch Vorteile, denn versuch mal Objektorientierten Mist mit Assembler zu bearbeiten
Ja es gibt Leute, die sowas wollen.
Das Ding ist halt das, dass du die Architektur bei OpenGL noch bauen musst, bei DirectX macht man das idr Auch, dann hast du ne Architektur über ner Architektur, was nur Zeit braucht und dich gerne auch in der Implementierung einschränkt.

Außerdem ist der Grund für den Geschwindigkeitsunterschied nicht der C-Style, sondern eben, dass DirectX einem mehr oder weniger Vorschreibt, wie man etwas zu implementieren hat. Edit: Und natürlich auch, dass die Grafikkartenhersteller das ganze implementieren und die bereits gucken, dass alles gut Läuft, bei DX ist das nicht so direkt der Fall wie bei OGL

Also Tatsache ist für eine reine Grafikkartenschnittstelle ist OOP Müll

COM ist eine zwar objektorienterte Architektur, aber ganz beschieden umgesetzt. Man kann aus solch C-Methoden viel schönere Sachen machen. Wenn man allerdings direkt damit arbeitet würde ich auch COM bevorzugen. Da es sich hier aber um eine Engine handelt, nehme ich an, dass der TE eine gewisse Abstraktion implementiert hat und DX/OGL seiner Architektur entsprechend anpasst. Soetwas klappt mit "C+Handles" imho viel besser.

Über die Doku habe ich mich nur geärgert, weil MS es anscheinend nicht für nötig hält mich darüber zu informieren, dass bei COM-Schnittstellen vor dem erschaffen CoInitialize() und nach dem Releasen CoUnInitialize() aufgerufen werden muss. Sonst gibts beim Releasen eine Accessviolation.

Also je nach Anwendungszweck ist Archiektur X besser. Wobei beide nicht das Gelbe vom Ei sind. In diesem Fall sollte er wie gesagt beide nehmen, einfach um die Möglichkeiten zu erweitern.

Msdn-Doku von CoInitialize() schrieb:

To close the COM library gracefully, each successful call to CoInitialize or CoInitializeEx, including those that return S_FALSE, must be balanced by a corresponding call to CoUninitialize.