DirectX oder OpenGL?
-
Flamewar!!

-
Macht doch nicht immer so eine Wissenschaft daraus.
Nehmt einfach irgendwas und fertig.Ansonsten hoffe ich, dass der liebe rapso das hier schließt. Wir wissen alle, wie das sonst endet.

-
wenn du ein spiel machen willst, schnapp dir ne fertige engine dafuer. alles selbst zu machen hat keinen sinn. mit d3d oder opengl dekst du gerade mal die graphik api ab, was ein bruchteil dessen ist was du brauchst um ein spiel zu machen.
-
Sag doch am besten einfach, was für ein Spiel du machen willst. Für ein 2D-Jump'n'Run wäre DirectX wohl ein bisschen übertrieben.
-
Hi,
großes PRO von DirectX gegenüber OpenGL:
Nicht nur 3D Grafik, sondern viel drumherum wenn man die D3DX Bibliothek aus dem SDK mitnutzt. Dann hat man direkt Klassen die Grafiken, 3D Modelle, ... aus Dateien laden können, eine umfassende hochoptimierte Mathebibliothek, und, und, und. Zudem ist DirectX mehr oder weniger objektorientiert, im Gegensatz zum OpenGL.
Ciao,
Stefan
-
Also Objektorentiert muss ja nicht unbedingt ein Vorteil sein, genau so, wie die ganzen beilagen nicht unbedingt ein Vorteil sein müssen. Sicher hat es Vorteile, wenn man jederzeit auf Beispiele und Zusatztools zugreifen kann, aber man wird deswegen nicht drum herum kommen, auch im Internet nach den sachen zu Suchen, die man Braucht, und je eher man das Macht, um so besser Prägt es sich ein. Und die Recourcen, die im Internet für OpenGL vorhanden sind bei weitem absolut nicht Beschränkt. Zugegeben, ich hab so gut wie keine Erfahrung mit Direct3D nur OpenGL, aber Dass OpenGL nicht objekt orientiert ist, find ich nicht sonderlich Tragisch, es Bleibt sehr übersichtlich, nur ein Namensbereich hätte ich mir anfangs gewünscht, aber an das Präfix gl von den Befehlen ist auch kein Weltuntergang.
-
Krux schrieb:
nur ein Namensbereich hätte ich mir anfangs gewünscht, aber an das Präfix gl von den Befehlen ist auch kein Weltuntergang.
namespace GL { #include <gl/gl.h> }
-
rapso schrieb:
Krux schrieb:
nur ein Namensbereich hätte ich mir anfangs gewünscht, aber an das Präfix gl von den Befehlen ist auch kein Weltuntergang.
namespace GL { #include <gl/gl.h> }
sshhht. mach das ganz schnell wieder weg

-
Also mal abgsehen davon das es lame is: geht das überhaupt?
Die Funktionen stehen doch in den Libs ohne Namespaces.
-
this->that schrieb:
Also mal abgsehen davon das es lame is: geht das überhaupt?
Ueber etwas nicht bescheid wissen, aber es als lame bezeichnen *hehehe*, entweder du bist sehr lustig, oder ich lach erst recht ueber diese hochqualitative aussage

danke
jeder darf mich hier noch einmal beschimpfen und dann aber zum topic zurueck

-
rapso schrieb:
this->that schrieb:
Also mal abgsehen davon das es lame is: geht das überhaupt?
Ueber etwas nicht bescheid wissen, aber es als lame bezeichnen *hehehe*, entweder du bist sehr lustig, oder ich lach erst recht ueber diese hochqualitative aussage

Was hat das eine mit dem anderen zu tun? Es ist nun mal in jedem Fall ein Hack, egal ob es nun geht oder nicht. Kein Grund sich hier gleich so aufzugeilen;)
-
ich bin zwar weder in opengl noch in directx der überprofi aber habe schon mit beidem gearbeitet
in directx (direct graphics /=direct 3d) hab ich mal vor längerer zeit angefangen ein 2d jump n run zu programmieren und dann etwas später nochmal dasselbe, nen partikel system ein bisschen mit 3d modellen rumprobiert und ne mini physik enginein opengl hab ich nen world of warcraft model importer geschrieben mit dem man wow modelle inklusive animation in opengl rendern kann mit shadern und auch ein partikelsystem in opengl
also ich würd sagen ich kenne mich gut aus aber würd mich längst nicht als profi bezeichnen, jedenfalls kurz und bündig wenn du ne antwor willst: opengl
wieso? weil du mit c++ arbeitest
direct rennt mittlerweile auf der .NET schiene und wenn du gesagt hättest du willst c# programmieren hätte ich dir XNA (nachfolger von managed directx) reingehämmertaber ich finde im vergleich zu unmanaged directx hat sich eigentlich entgegen meiner erwartungen opengl als einfacher zu benutzen herausgestellt, wobei es kein so großer unterschied ist
aber irgendwie ist es unter c++ angenehmer mit opengl zu arbeiten, zumindest hab ich den eindruck
wie auch immer, ich würd dir jedenfalls empfehlen trotzdem nicht c++ zu machen sondern in c# zu programmieren und XNA zu verwenden weil du dich damit wirklich aufs programmieren konzentrieren kannst und nicht auf diese ganzen speicherspiele die du in c++ hast achten musst
und als shader nimm CG von nvidia die rennen auf directx und opengl
-
this->that schrieb:
rapso schrieb:
this->that schrieb:
Also mal abgsehen davon das es lame is: geht das überhaupt?
Ueber etwas nicht bescheid wissen, aber es als lame bezeichnen *hehehe*, entweder du bist sehr lustig, oder ich lach erst recht ueber diese hochqualitative aussage

Was hat das eine mit dem anderen zu tun? Es ist nun mal in jedem Fall ein Hack, egal ob es nun geht oder nicht. Kein Grund sich hier gleich so aufzugeilen;)
dann schau doch mal in die c*-header deiner c++-implementierung rein. da finden sich reihenweise diese "hacks" wie
cstdio:
namespace std
{
#include <stdio.h>
};
-
Und wie funktioniert dann das Linken?
ein strcmp heißt dann std::strcmp, aber in der lib steht nach wie vor nur strcmp.
-
wie wäre es denn mit openGL in D anstatt C++, das hat auch automatische Speicherbereinigung. Es gibt sogar leute, die das Benutzen, und was auf die Beine gestellt haben. http://www.asahi-net.or.jp/~cs8k-cyu/index_e.html
-
Vevusio schrieb:
@topic
direct rennt mittlerweile auf der .NET schiene und wenn du gesagt hättest du willst c# programmieren hätte ich dir XNA (nachfolger von managed directx) reingehämmertSo eine falsche Aussage kann man natürlich nicht stehen. DirectX rennt NICHT auf der .Net Schiene. Die .NET Version von DX war stets eine Alternative zum nativen DX. Seit der Begrabung von MDX, der Einführung von XNA und der Entscheidung, dass es DX10 nur noch nativ gibt, ist managed DX effektiv tot (XNA ist NICHT gleichzusetzen mit MDX).
Und die Aussage, dass sich unter C++ mit OpenGL leichter entwickeln lässt ist angesichts des veralteten prozeduralen Designs von OpenGL und des objektorientierten Aufbaus von DX schon eine Farce;)
-
Objektorientier ist aber auch nicht gleichzusetzen mit Besser. Nur weil es häufiger angewandt wir, und es bereits Rein Objektorientierte Sprachen gibt, finde ich kann man noch lange nicht sagen, dass alles andere Veraltert ist. Ich finde die art, wie OpenGL die dinge handhabt auch gut, Die unstellung von Objektorientiert nach nicht objektorientiert kostet natürlich Zeit, Aber das als Veraltert zu bezeichen kann man bei weiten nicht sagen. Nicht alles ist mit Klassen besser Strukturiert, als ohne sie, nicht ohne Grund haben wir an der Uni im ersten Semester Scheme Programmiert, wobei das nun wirklich kein gebräuchliche Sprache ist.
-
Was glaubst du wohl warum soch Objektorientierung durchgesetzt hat und es heute DAS Programmiersprachenparadigma ist? Richtig, weil es enorm viele Vorteile hat wie leichtere Modellierung der Welt, bessere Handhabung komplexer Beziehungen usw. usw.
Der typische C-Programmierstil ist heutzutage nun mal größtensteils einfach veraltet. Und wir reden hier nicht von Embedded-System, sondern von größeren Systemen wie Spielen/Engines etc.
Natürlich ist OOP nicht per se besser, aber es hat einfach unglaublich viele Vorteile gegenüber prozeduraler Programmierung. Und ein riesiger Batzen unstrukturieter Funktionen, Präfixe statt Namespaces usw. IST aus heutiger Sicht einfach veraltet. Was glaubst du, warum in OGL3.0 das API Design/die Code Struktur grundlegend umgebaut wird?;)
Und ihr habt in der Uni mit Sicherheit nicht Scheme durchgenommen, weil es gegenüber OO-Sprachen so toll strukturiert ist oder sich besser programmieren lässt.

-
this->that schrieb:
Was glaubst du wohl warum soch Objektorientierung durchgesetzt hat und es heute DAS Programmiersprachenparadigma ist? Richtig, weil es enorm viele Vorteile hat wie leichtere Modellierung der Welt, bessere Handhabung komplexer Beziehungen usw. usw.
Falsch, nur weil etwas eine klasse ist, ist es noch lange nicht objektorientiert. eine statemaschine bleibt eine statemaschine.
Der typische C-Programmierstil ist heutzutage nun mal größtensteils einfach veraltet. Und wir reden hier nicht von Embedded-System, sondern von größeren Systemen wie Spielen/Engines etc.
der meiste code ist oop, aber recht schlecht, schau dir z.b. d3d10 an mit 10 klassen fuer buffer, wo eine klasse reichen wuerde.
was man sonst an c code sieht ist da qualitativ besser.Natürlich ist OOP nicht per se besser, aber es hat einfach unglaublich viele Vorteile gegenüber prozeduraler Programmierung. Und ein riesiger Batzen unstrukturieter Funktionen, Präfixe statt Namespaces usw. IST aus heutiger Sicht einfach veraltet. Was glaubst du, warum in OGL3.0 das API Design/die Code Struktur grundlegend umgebaut wird?;)
ID3D10Device, ID3D10Buffer, ID3D10...
-
rapso schrieb:
this->that schrieb:
Was glaubst du wohl warum soch Objektorientierung durchgesetzt hat und es heute DAS Programmiersprachenparadigma ist? Richtig, weil es enorm viele Vorteile hat wie leichtere Modellierung der Welt, bessere Handhabung komplexer Beziehungen usw. usw.
Falsch, nur weil etwas eine klasse ist, ist es noch lange nicht objektorientiert. eine statemaschine bleibt eine statemaschine.
Und welche meiner von dir zitierten Aussagen war nun falsch?
der meiste code ist oop, aber recht schlecht, schau dir z.b. d3d10 an mit 10 klassen fuer buffer, wo eine klasse reichen wuerde.
Was für 10 Buffer Klassen in D3D10? Ich kenne nur den generischen ID3D10Buffer, und der ist abgeleitet von einer Ressource (was absolut Sinn macht).
was man sonst an c code sieht ist da qualitativ besser.
Was man sonst WO sieht? In OpenGL?
ID3D10Device, ID3D10Buffer, ID3D10...
Das hätte man mit Sicherheit eleganter lösen können in DX. Aber ich habe ja auch nirgends behauptet, dass DX perfekt ist.
PS: Ich würde noch immer gerne wissen, wie das beim Linken funktioniert, wenn ich einfach den Header einer Lib in einen Namespace packe.