DirectX oder OpenGL?

[this-*gt*that]

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;)

[Vevusio]

@topic

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 engine

in 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ämmert

aber 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

[Jester]

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>
};

[this-*gt*that]

Und wie funktioniert dann das Linken?

ein strcmp heißt dann std::strcmp, aber in der lib steht nach wie vor nur strcmp.

[Krux]

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

[this-*gt*that]

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ämmert

So 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;)

[Krux]

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.

[this-*gt*that]

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.

[rapso]

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...

[this-*gt*that]

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.

[rapso]

this->that schrieb:

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?

das was du als richtig argumentiert hast

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).

IndexBuffer,VertexBuffer,ConstBuffer,pixel/geometry/vertexshader (was nur buffer sind) etc.

was man sonst an c code sieht ist da qualitativ besser.

Was man sonst WO sieht? In OpenGL?

schau dich in sourceforge um, da gibt es, trotz deiner behauptung dass alles oop wird, noch massig c code.

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.

hier wird dauernd fuer d3d beworben mit 'objekt orientiert' was es kaum ist, jedenfalls auf keine sonderlich gute art.

PS: Ich würde noch immer gerne wissen, wie das beim Linken funktioniert, wenn ich einfach den Header einer Lib in einen Namespace packe.

versuchs

[this-*gt*that]

rapso schrieb:

das was du als richtig argumentiert hast

Du willst jetzt also ernsthaft behaupten, dass OOP NICHT viele Vorteile bzgl. Modellierung und Ausdrückung von Beziehungen hat?

rapso schrieb:

IndexBuffer,VertexBuffer,ConstBuffer,pixel/geometry/vertexshader (was nur buffer sind) etc.

Sowohl IB,VB als auch CB werden durch die generische Klasse ID3D10Buffer ausgedrückt. Was ein PS/GS/VS Buffer sein soll ist mir nicht klar. Du behauptest es gäbe viele Buffer Klassen, aber genau das Gegenteil ist der Fall.

schau dich in sourceforge um, da gibt es, trotz deiner behauptung dass alles oop wird, noch massig c code.

Verdreh bitte nicht meine Aussagen. Ich habe NIRGENDS gesagt das ALLES OOP wird. Ich habe gesagt, dass sich OOP durchgesetzt hat und heute DAS Paradigma ist. Wenn man heutzu tage ein größeres System im 3D Umfeld plant, wird das mit sehr, sehr großer Wahrscheinlichkeit OOP. Alle neueren Engines sind OOP und auch nahezu alle Spiele sind OOP. Und das die neueren Sprachen wie Java,C# und D alle OOP sind, ist auch kein Zufall.

hier wird dauernd fuer d3d beworben mit 'objekt orientiert' was es kaum ist, jedenfalls auf keine sonderlich gute art.

Da stimme ich dir zu. Die OOP in D3D ist sehr zweifelhaft. Ich würde mal sagen, sie haben auch zu gunsten der Performance auf ein ganz striktes und sauberes OOP Design verzichtet.

PS: Ich würde noch immer gerne wissen, wie das beim Linken funktioniert, wenn ich einfach den Header einer Lib in einen Namespace packe.

versuchs

Hm, jetzt musste ich extra wegen dir ein neues C++ Projekt anlegen.
Ich habe lediglich stdio.h inkludiert und mit printf was ausgegeben. Als ich dann stdio.h in einen Namespace gepackt habe, kam wie erwartet ein Fehler:

Error 1 error C3861: 'printf': identifier not found main.cpp 6

[sothis_]

ich würde das nicht gerade mit der stdio.h versuchen aber grundsätzlich funktioniert es, da der namespace im mangled name hinter dem funktionssymbol aufgeführt wird und erst zum tragen kommt, wenn mehrere symbole mit gleichem bezeichner exisiteren (das, wie auch immer, ist eine vermutung meinerseits :P)

#include <windows.h>
#include <iostream>

static const char* test = "I am not OpenGL";

namespace OGL
{
	#include <GL/gl.h>
}
namespace OGL2
{
	const char* glGetString(unsigned int);
	const char* glGetString(unsigned int name)
	{
		return test;
	}
}

int main(int argc, char* argv[])
{
	if (OGL::glGetString(GL_VERSION) == NULL)
	{
		std::cout << "error: " << OGL::glGetError() << std::endl;
	}
	else
	{
		std::cout << OGL::glGetString(GL_VERSION) << std::endl;
	}

	if (OGL2::glGetString(GL_VERSION) == NULL)
	{
		std::cout << "error: " << OGL::glGetError() << std::endl;
	}
	else
	{
		std::cout << OGL2::glGetString(GL_VERSION) << std::endl;
	}
	return 0;
}

sollte mit

cl /EHsc test.cpp opengl32.lib

fehlerfrei kompilieren/linken und folgendes ausgeben:

error: 1282
I am not OpenGL

[Gast]

this->that schrieb:

rapso schrieb:

das was du als richtig argumentiert hast

Du willst jetzt also ernsthaft behaupten, dass OOP NICHT viele Vorteile bzgl. Modellierung und Ausdrückung von Beziehungen hat?

Objektorientierung wird schon massiv überbewertet. Was Objektorientierung wirklich wesentlich von anderen Paradigmen (wie zum Beispiel Objektbasiertheit) unterscheidet, ist die Vererbung. Ich bin in den letzten Jahren immer mehr dazu übergegangen, weniger Vererbung einzusetzen, weil es in vielen Fällen ein sehr künstliches Konstrukt ist, was man überall aufzwängt. Vererbung ist zwar nicht immer schlecht, aber wird viel zu häufig benutzt. Zum Beispiel braucht die Menschheit nicht, dass man einer Sortier-Funktion ein abgeleitetes Vergleichsobjekt übergibt, es ist aber derzeit furchtbar in, sowas zu designen.

Konzepte wie Kapselung usw. gibt es auch außerhalb von Klassen. Sieh dir zum Beispiel die ganzen Betriebssystem-APIs an, du kriegst ein Handle auf verschiedene Objekte, die sind selber auch perfekt weggekapselt.

Überhaupt profitierst du gar nicht so stark davon, wenn Direct3D sowas ähnliches wie objektorientiert ist. Du musst so oder so eine Art Schicht darüberlegen, die dann higher-level Aufgaben übernimmt, wie das Bereitstellen einer Zeichenfläche, das Rendern von ganzen Models, Text, usw. und darauf baust du dann erst deine 3D-Engine auf. Diese höhere Schicht kannst du dann gestalten, wie es sinnvoll ist, das darunterliegende API ist ziemlich egal.

[this-*gt*that]

sothis_ schrieb:

ich würde das nicht gerade mit der stdio.h versuchen

Wieso? Was ist an stdio.h so besonderes? Naja, zeigt es doch zumindest eines: Dieser Hack geht nicht generell.

@Optimizer: Ob es überbewertet wird oder nicht weiß ich nicht. Aber Fakt ist nun mal, dass es viele Vorteile bietet um gewisse Dinge auszudrücken und große System zu designen.
Vererbung ist ein praktisches Mittel um Hierarchien zu beschreiben. Das einzige was ich schlecht finde, sind tiefe Vererbungshierarchien wie z.B. in Java. Aber so Hierarchien der Stufe 2 oder grade noch 3 können sehr angenehm sein.

Und ich sehe schon einen kleinen Unterschied zwischen einem Handle, das im Grunde nix weiter ist als eine Zahl, und einem Objekt, das Daten und Fähigkeiten kapselt.

Dein letzter Punkt ist teils richtig, teils auch wieder nicht. Auch wenn ich eine Engine schreibe, muss ich mich mit der API auseinandersetzen. Und dann ist es doch angenehmer, wenn die API einigermaßen angenehm aufgebaut ist (und ich empfinde Klassen wie einen Buffer, der alle Buffer-Sachen kapselt, wesentlich angenehmer als hunderte globale Funktionen). Desweiteren braucht man nicht immer gleich eine Engine. Ich habe z.B. noch nie eine Engine geschrieben - ich schreibe direkt Anwendungen auf D3D. Wenn man einfach nicht immer wieder den selben "Typ" von Spiel erschafft, macht das aufwändige planen und programmieren einer Engine keinen Sinn. In den meisten Fällen ist für mich das Wort "Engine" nur noch ein Buzzword. Da erstellt jemand ein paar Vektor und Matrixklassen und einen ASE Fileloader und gleich ist es eine Engine. Was wirklich vorzeigbares sieht man jedoch nicht.
Man könnte fast sagen mein Fazit ist: Schreibt Spiele/Anwendungen und keine Engines;)
Und selbst wenn man eine Engine plant dann wird die, da wirste mir mit Sicherheit zustimmen, mit sehr hoher Wahrscheinlichkeit objektorient aufgebaut sein;)

[Gast]

this->that schrieb:

@Optimizer: Ob es überbewertet wird oder nicht weiß ich nicht. Aber Fakt ist nun mal, dass es viele Vorteile bietet um gewisse Dinge auszudrücken und große System zu designen.

Vererbung ist ein praktisches Mittel um Hierarchien zu beschreiben. Das einzige was ich schlecht finde, sind tiefe Vererbungshierarchien wie z.B. in Java. Aber so Hierarchien der Stufe 2 oder grade noch 3 können sehr angenehm sein.

Gerade ein paar Klassenhierarchien sind viel zu "klein" für große Systeme. Klassen sind gut, wenn ich sowas wie eine Bruchrechnen-Klasse schreibe, aber von daher kann man noch lange nicht darauf schließen, wie man eine ganze Anwendung baut. Hierarchien müssen auch nicht immer was mit Vererbung zu tun haben, sondern lassen sich öfter als der Durchschnittsprogrammierer glaubt ohne Vererbung besser realisieren.

Und ich sehe schon einen kleinen Unterschied zwischen einem Handle, das im Grunde nix weiter ist als eine Zahl, und einem Objekt, das Daten und Fähigkeiten kapselt.

Ja, kann man machen wie man will. In beiden Fällen ist es noch nicht objektorientiertes Design. Es ist nur nie schlecht, sich bewusst zu machen, dass es mehrere Möglichkeiten gibt.

Dein letzter Punkt ist teils richtig, teils auch wieder nicht. Auch wenn ich eine Engine schreibe, muss ich mich mit der API auseinandersetzen. Und dann ist es doch angenehmer, wenn die API einigermaßen angenehm aufgebaut ist (und ich empfinde Klassen wie einen Buffer, der alle Buffer-Sachen kapselt, wesentlich angenehmer als hunderte globale Funktionen).

Wieder, es hat noch nichts mit Objektorientierung zu tun. D3D ist zwar sogar ein bisschen Objektorientiert, zum Beispiel weil das meiste Zeug von IUnknown erbt, aber das macht noch kein gutes objektorientiertes Design. Sachen wie IDirect3DSurface9** machen es auch nicht gerade besser. Hier denk ich mir schon manchmal, so schlimm wäre ein Handle jetzt auch nicht.

Desweiteren braucht man nicht immer gleich eine Engine. Ich habe z.B. noch nie eine Engine geschrieben - ich schreibe direkt Anwendungen auf D3D.

Eine Engine schreibst du im gewissen Sinne immer mit, ist halt die Frage, wie gut man sie weiterverwenden kann. Aber du wirst doch sicherlich zwischen dem Grafik-API und deinen Game-Objekten eine Abstraktionsschicht haben. Normalerweise gibt es die Spielwelt aus mehreren Sichten, z.B. KI-Sicht, Grafik-Sicht, Physik-Sicht, ...

Und selbst wenn man eine Engine plant dann wird die, da wirste mir mit Sicherheit zustimmen, mit sehr hoher Wahrscheinlichkeit objektorient aufgebaut sein;)

Ich würde nicht eine "ganze" Engine objektorientiert aufbauen. Natürlich verwende ich Klassen, natürlich gibt es ab und zu eine Ableitung. Das meiste ist aber nicht objektorientiert (die Verwendung von Klassen macht noch kein OO-Design), sondern Komponentenbasiert.

Vor allem im Entitätenmanagement halte ich das für die bessere Wahl. Jedes Objekt ist erstmal nur eine ID und man weiß nicht so wirklich, aus was es eigentlich besteht. Wenn ich ein Objekt dann anremple, schau ich beispielsweise nach, ob es eine Physik-Komponente für diese ID gibt und lass es vom Tisch runterfallen, oder zum Rendern hole ich mir alle Renderable-Komponenten. Da ist praktisch keine Vererbung im Spiel. Der große Vorteil davon ist, ich kann jederzeit ändern, aus was ein bestimmtes Objekt besteht und muss nicht eine riesige Hierarchie (u.U. mit Mehrfachvererbung auch noch) refactoren.