DirectX oder OpenGL?

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