Wann kommt neues OpenGL?

Sgt. Nukem

Original erstellt von Artchi:
**OpenGL ist eine einfache Statuspipeline, da macht OO nicht sehr viel Sinn bzw. gar keinen Sinn! Das ist ja gerade der Vorteil von OpenGL, da man es somit auch auf jede Plattform einsetzen kann. COM ist doch MS-spezifisch...
**

Wieso macht OOP keinen Sinn dann??
Was soll das bitte für ein "Vorteil" sein??
Wieso kann man OOP NICHT auf jeder Plattform einsetzen??
Warum verstehst Du unter OOP direkt COM??

**Wenn ich aber etwas wie D3D habe, dann hab ich doch praktisch schon eine Mini-3D-Engine. OK, ich bin jetzt D3D-mäßig nicht auf dem neuesten Stand. Aber ich kann mich noch an DX 6.0 erinnern, da sah mir das verdammt nach eine Mini-3D-Engine aus. Auch Java3D ist OO und kommt mir einer Mini-3D-Engine nahe.
**

D3D = Mini-3D-Engine??
Stimmt!
g_pDirect3D = Direct3DCreate9(D3D_SDK_VERSION);
g_pDirect3D->LoadLevel("TheLongestYard.bsp");

OpenGL will das aber nicht, es soll einfach nur den Status des 3D-Chips setzen und man selber als Coder schiebt ein paar Daten durch die Pipeline. Fertig. Nur so ist gewehrleistet das es einfach und problemlos überall implementierbar ist. Wer OO will, muß ne 3D-Engine aufsetzen, fertig.

????? ?????

Also wenn ihr alle so auf das 0ldsk00l Design abfahrt, wozu dann überhaupt OpenGL 2.0??
Plagt euch weiter mit Hunderten völlig gleichberechtigter, ungeordneter Funktionen rum, und den geilen Extensions...

Plassy

Also wenn ihr alle so auf das 0ldsk00l Design abfahrt, wozu dann überhaupt OpenGL 2.0??
Plagt euch weiter mit Hunderten völlig gleichberechtigter, ungeordneter Funktionen rum, und den geilen Extensions...

was soll das heißen... sollen die ganzen funktionen private gemacht werden??
wie soll man denn dann noch damit programmieren??

und wo ist denn ogl bitte ungeordnet??

ich würde nicht sagen, dass wir uns damit rumplagen...
es ist wohl eher ein vergnügen
richtig müsste es dann heißen:

Also wenn ihr alle so auf das 0ldsk00l Design abfahrt, wozu dann überhaupt OpenGL 2.0??
vergnügt euch weiter mit Hunderten völlig gleichberechtigter, ungeordneter Funktionen, und den geilen Extensions...

:D:D:D

mfg
Plassy

[ Dieser Beitrag wurde am 26.06.2003 um 12:29 Uhr von Plassy editiert. ]

Sgt. Nukem

Ich finde dann solltet ihr auch Vergnügungssteuer zahlen...!

SnorreDev

Plag du dich doch mit dem alle 1,5 Jahre komplett neuen IFace rum - oder sind die steps nicht mehr so groß wie von 7 auf 8?

Pst - sag das nicht zu laut mit der Vergnügunssteuer - sonst könnte es Schröder noch hören *g

[ Dieser Beitrag wurde am 26.06.2003 um 13:45 Uhr von SnorreDev editiert. ]

Original erstellt von SnorreDev:
Plag du dich doch mit dem alle 1,5 Jahre komplett neuen IFace rum - oder sind die steps nicht mehr so groß wie von 7 auf 8?

Seit wann war der Stepp von 8 auf 9 groß? Okay von 7 auf 8 war sogesehen auch kein großer stepp nur für 3D, aber 2D absolut nicht. Ich weis gar net was ihr damit immer für probleme habt?

KXII

ich muss sagen, auch wenn d3d auf com aufbaut, merkt man davon eigentlich nichts. man muss zumindest nichts über com wissen um d3d benutzen zu können.

was mich an opengl stört ist, das man einfach so mitten irgendwo im programmcode ein glVertex3f() hinschreiben kann. vollkommen zusammenhangslos. keiner weis wo das teil landet (klar es wird zur pipleine geschickt, aber trotzdem...). auch strukturierte designs sollten sich etwas an "oo" halten und sinnvolle strukturen bilden. ein einfaches glVertex3f hat nicht viel mit strukturierung zu tun finde ich, man sollte diese art der "3dporgrammierung" abschaffen und vollkommen durch vertexbuffer ersetzen, dann weiß auch jeder was gemeint ist.

hmm ... das stimmt auch wieder.

naja, vollkommen kann man sowas nicht verbieten. in c++ ist ja auch sowas "erlaubt" (kompilierbar):

int* i = 0;
*i = 7;

Helium

Würde euch so etwas gefallen?
OGLGraphicDevice->gl2Vertex3f(...)

Nein, das wäre knontraproduktiv. Wer sowas bastelt, hat keine Ahnung Objektorientierung.

genau. schließlich gehören ja auch namensbereiche und überladene funcs dazu...

Nein. Namensbereiche haben absolut nichts mit OO zu tun. Ob das Überladen von Methoden daugehört, darüber kann man sich streiten. Ich meine nein. (bitte nicht drauf eingehen, da das nicht zum Thema passtf="java\1: x

Das ist ja gerade der Vorteil von OpenGL, da man es somit auch auf jede Plattform einsetzen kann

Du bist immernoch eine Antwort Schuldig, warum OOP nicht Plattformübergreifend eingesetzt werden kann.

Kann es sein, das nur die, die der Meinung sind Klassen == Objektorientierung hier posten (bis auf wenige Ausnahmen)? Es heißt Objektorientierung und nicht Klassenorientierung. Ist euch das schon mal aufgefallen?

Plassy

ne klasse ist doch ein objekt...

mfg
Plassy

KXII

...Ob das Überladen von Methoden daugehört, darüber kann man sich streiten

nein darüber kann man sich absolut NICHT streiten. das überladen von funktionen hat überhaupt gar nichts mit objektorientierter programmierung zu tun! ich kann auch nicht nachvollziehen was daran so schwer zu verstehen sein sollte?!?

Original erstellt von Plassy:
**ne klasse ist doch ein objekt...

mfg
Plassy**

Naja aber daraus bestimmt nun wirklich nicht die 100%ige OOP. wenn nur so 15% höchstens! :p

KXII

@helium

ich würde das nicht so streng sehen mit oo=klassenorientierung.

klassen sind auch nur strukturen, und wenn du anstatt "class XYZ" "struct XYZ" benutzt und dann anstatt die funktionen IN die klasse selber schreibst, sie AUSSEN hin schreibst, ist das doch selbe nur in grün; deshalb gleich zu sagen: "man kann auch objektorientiert programmieren ohne "CLASSen" zu benutzen", dann ist das nicht richtig oder anders gesagt, nur die halbe wahrheit.

es gibt halt viele programmierer die das nicht so bis ins detail sehen und deshalb sagen klassen=objekte und deshalb objektorientierte programmierung = programierung mit klassen. lass sie doch einfach.

mit welcher sprache willst denn OHNE strukturen/klassen objekte bilden können und diese instanzieren? denn das bilden einer instanz ist ein wesentliches merkmal oop.

warum soll überladen von funktionen nicht zu oop gehören?
ich kenne C nicht so genau, aber soweit ich weiß is das da nicht möglich

scheiße, vergesst mein letztes Posting. ich sag jetzt nix mehr dazu ....

KXII

ich wollte schon gerade sagen...

das kann nicht dein ernst sein!

Helium

ne klasse ist doch ein objekt...

Also das ist ja nun der größte Käse, den ich seit langem gehöt habe. Ich kann auch nicht sagen Holz ist ein Schrank, nur weil mein Schrank aus Holz ist.

Das Objekt entsteht erst bei der Instanzierung der Klasse oder allgemeiner bei der Instanzierung des Typs.

mit welcher sprache willst denn OHNE strukturen/klassen objekte bilden können und diese instanzieren? denn das bilden einer instanz ist ein wesentliches merkmal oop.

Ein Objekt ist bereits eine Instanz und kann nicht mehr instanziert werden.

int x; // jetzt hab ich eine Instanz von int erstellt

struct Foo { ... } y; // jetzt hab ich ne Instanz von Foo erstellt.

Ich sehe sofort, das das Instanzieren eines Typs absolut OOP-Typisch ist, da man weder in funktionalen noch struktorierten Sprachen Variablen verwendent. Denk darüber bitte nochmal nach. Das stimmt nämlich nicht so ganz.

Der Unterschied leigt in folgendem:

if (monster_x == held_x && monster_y == held_y) {
   held_leben = 0;
   spiel_beenden();
}

Nun erstelle ich doch mal schnell ein paar Klassen und denke ich könnte nun OO proggen.

if (monster.x == held.x && monster.y == held.y) {
   held.leben = 0;
   spiel_beenden();
}

Und? Ist das OO? nicht wirklich.

Versuchen wirs nochmal (natürlich verwenden wir wieder Klassen, aber etwas anders):

if (monster.faeng(held)) {
   held.stirb();
   spiel_beenden();
}

Und tada. Selbst jemand, der nicht Progrmmieren, kann mit dem unteren fast was anfangen, wärend das obere eher nach Mathe aussieht.

Bashar

In Smalltalk und CLOS sind Klassen auch Objekte.

> (defclass foo () ())
#<Standard-Class FOO #xFFAAF0>

> (type-of (find-class 'foo))
STANDARD-CLASS

KXII

@helium

...Ein Objekt ist bereits eine Instanz und kann nicht mehr instanziert werden

also ehrlich, glaubst du wirklich das ich das nicht wüsste??? !

das ist eine sehr einfache und eingeengte sicht von dir, die auch sehr oft von anfängern gebraucht wird (ich hoffe du bist keiner). man sollte das nicht so "streng" sehen. ein objekt ist ein abtraktes gebilde im allgemeinen sinne; und ein instaziertes gebilde kann man auch als objekt bezeichnen, es ist aber nicht zwingend! warauf es ankommt ist zu unterscheiden zwischen der definition eines objektes und der instanzierung eines objektes. wie man diese zwei dinge genau bezeichnet ist nicht relevant. wichtig ist nur das andere wissen was gemeint ist. ich würde niemandem etwas vorwerfen, wenn er das nicht 100% korrekt ausdrückt. mann muss nicht unbedingt zu einem instanzierten "ding" objekt sagen. das ist das selbe, wie wenn man zu funktionen methoden sagen soll. das ist doch blödsinn sich auf solche kleinigkeiten zu beschränken.

du hast geschrieben:

**```cpp
Ich sehe sofort, das das Instanzieren eines Typs absolut OOP-Typisch ist, da

man weder in funktionalen noch struktorierten Sprachen Variablen verwendent.

Denk darüber bitte nochmal nach. Das stimmt nämlich nicht so ganz.

Der Unterschied leigt in folgendem:

if (monster_x == held_x && monster_y == held_y) {
held_leben = 0;
spiel_beenden();
}
Nun erstelle ich doch mal schnell ein paar Klassen und denke ich könnte nun OO proggen.

if (monster.x == held.x && monster.y == held.y) {
held.leben = 0;
spiel_beenden();
}
Und? Ist das OO? nicht wirklich.

Versuchen wirs nochmal (natürlich verwenden wir wieder Klassen, aber etwas anders):

if (monster.faeng(held)) {
held.stirb();
spiel_beenden();
}
Und tada. Selbst jemand, der nicht Progrmmieren, kann mit dem unteren fast was anfangen, wärend das obere eher nach Mathe aussieht.


wenn nur das letzte beispiel für dich OOte programmierung ist, ... naja ... ich hoffe es nicht!  

ich sehe das alles aus einer ganz anderen und viel abtrakteren perspektive. du beschränkst dich wieder auf kleinigkeiten.  

bei OO geht es doch darum, funktionalität in sinnvolle gruppen zu packen und zwar in einer form, die es erlaubt, instzanzen davon bilden zu können. man beschreibt diese gruppen (oft als klassen bezeichnet) und bildet objekte davon, die eine bestimmte lebenszeit haben. es gibt ein eindeutiges davor ein jetzt und ein danach. das ist im groben alles, und wie man es realisiert ist völlig egal. wichtig ist, das man von globalen variablen/objekte wegkommt, die IMMER existieren und nur EIN mal. man könnte es auch als individualisierung bezeichnen.  

der unterschied von  

held_leben = 0;  

und  

"held.leben = 0;"  

und  

"held.stirb();"  

liegt doch nur in der schreibweise.  

die FUNKTIONALITÄT die dahinter steckt ist in allen fällen die selbe. natürlich ist die dritte variante etwas besser gekapselt (das liegt aber nur an c/c++), weil man eine funktion aufruft und man dadurch eine INDIREKTE wertezuweisung ermöglicht, aber das ist doch absolut programmiersprachenabhängig oder anders gesagt designabhängig. man könnte genausogut der instanz "leben" von "held" einen zuweisungsoperator hinzufügen, der nichts anderes macht als eine funktion aufzurufen, die den wert dann indirekt zuweist. das ist dann das selbe (optisch gesehen) wie beim dritten beispiel. oder mann könnte es auch ganz anders machen; es gibt unendlich viele möglichkeiten um diese funktionalität zu realisieren und darzustellen.  

(ganz krass gesagt, man müsste es noch nicht einmal optisch darstellen. mann könnte es auch akustisch machen, mit einer sprache - einen entsprechenden computer und software vorausgesetzt. wäre das dann für dich NICHT mehr OO nur weil man die funktion nicht mehr sehen kann, und sie dadurch natürlich nicht mehr das aussehen wie in beispiel 3 hat?)  

ein einfacherer weg wäre es per "drag and drop" zu machen. das wäre auch OO, auch wenn nirgend steht "abc=blabla;" oder "abc(blabla)" oder sonstwas.  

[ Dieser Beitrag wurde am 27.06.2003 um 22:14 Uhr von **KXII** editiert. ]

Helium

OK, verdeutliche ich es etwas. ERsetze den zweiten Teil meines Beispiels durch folgendes. Der Text bleibt der selbe:

if (monster.get_x() == held.get_x() && monster.get_y() == held.get_y()) {
   held.set_leben(0);
   spiel_beenden();
}

Aussage von mir ist immer noch die selbe: Das ist nicht OOP. Das ist pseudogekapsele, das bis auf die Tatsache, das es mehr schreibarbeit ist nichts ändert. Es ist aber schonmal ein großer schritt, da das direkte Setzen der Position verhindert wird, da kein set_x bzw, set_y existiert.

bei OO geht es doch darum, funktionalität in sinnvolle gruppen zu packen und zwar in einer form, die es erlaubt, instzanzen davon bilden zu können. man beschreibt diese gruppen (oft als klassen bezeichnet) und bildet objekte davon, die eine bestimmte lebenszeit haben. es gibt ein eindeutiges davor ein jetzt und ein danach. das ist im groben alles, und wie man es realisiert ist völlig egal.

Man bezeichnet diese "Gruppen" immer als Klassen. Und jede Variable in jeder Sprache hat irgendeine Zeit wärend der sie existiert. Da hat nix mit OO zu tun.

wichtig ist, das man von globalen variablen/objekte wegkommt, die IMMER existieren und nur EIN mal. man könnte es auch als individualisierung bezeichnen.

Ach und bei der strukturierten. Ja aber das war in der struktorierten programmierung doch genauso. Man versucht alle Variablen lokal in Funktionen anzulegen. Bei manchen ging das nicht. die wurden dann global. Jetzt packst du Sie als statisches Element in eine Klasse oder bstelst ein Singleton drumherum. Technisch gesehen ist das doch das selbe.

der unterschied von

held_leben = 0;

und

"held.leben = 0;"

und

"held.stirb();"

liegt doch nur in der schreibweise.

Nein. Das hast du eben nicht verstanden. Die Schreibweise ist völlig egal. Es geht einzig und allein um die Semantik.