Was kommt nach DirectX??

[energyzer]

Kane schrieb:

Ich habe prinzipiell nichts gegen MS-Apis oder DirectX, wenn sie nur über
die Jahre gleichbleiben würden.

OpenGL wurd 1992 released und ist heute immer noch zu den damaligen Programmen
kompatibel. Ich wüßte jetzt keine Funktion die gestrichen, umgebaut oder umbenannt wurde.
Ich will halt nicht jedes Jahr ein "neues" DirectX lernen..

Ich denke, da ist der Unterschied zu DX nicht groß. Ob ich nun zur Ausführung
eines Programms neue Extensions installieren muss oder mein DX update, dass
kommt aufs Gleiche raus.

Auch bei der Entwicklung sehe ich nicht den Unterschied. Alte Programme sind
100%ig kompatibel, da alte DX Versionen generell erhalten bleiben.

Ok die neuste Version hat dann ein paar Unterschiede. Aber die machen sich
zumeist nur in neuen Interfaces und kleinen Unterschieden in den Funktions-
aufrufen bemerkbar. Und dadurch entsteht ja auch ein Art Evolution von
DX - schließlich ist mitleerweile vieles anderes als 1992

[dot]

otze schrieb:

winapi wirds auch nichmehr geben

afaik doch...

WGF is als Direct3D 10 unter einen decknamen zu sehen und wird sich von DirectX 9.0 vom aufbau her vermutlich nicht extrem unterscheiden ( außer natürlich dass es nicht mehr auf COM basiert, VertexShader 4.0 unterstützt usw... )

da microsoft ja mit COM aufhört, musste das mal passieren

was mit den andren komponenten passiert weis ich auch nicht genau, aber ich denke nicht, dass das alles einfach ausstirbt.

interpreter schrieb:

otze schrieb:

obwohl ja ein schöneres design von DX nich allzu schlecht wär...

Stimmt.
Aber wenn ich mir die bisherigen MS-APIs anschaue (WinApi, MFC, DX etc.) habe ich Zweifel, dass die dazu in der Lage sind

was gibts an der WinApi auszusetzen!?

[SideWinder]

Was gibts an DX auszusetzen? Ist ja eine schöne strike COM-Library. Immer noch besser als etwas funktionsorientiertes dauernd wrappen zu müssen!

MfG SideWinder

[rüdiger]

was gibts an der WinApi auszusetzen!?

lol, dass muss man nicht fragen, wenn man schon einmal mit der WinAPI gearbeitet hat. Die WinAPI ist ein riesiger undurchschauberer Brocken an unglaublich hässlichen C Funktionen mit einer absolut hirnrissigen Namenskonvention.

Willst du mir nicht glauben? Schlagen wir einfach mal die MSDN auf

HANDLE CreateFile(LPCTSTR lpFileName,DWORD dwDesiredAccess,DWORD dwShareMode,  LPSECURITY_ATTRIBUTES lpSecurityAttributes,DWORD dwCreationDisposition,DWORD wFlagsAndAttributes,HANDLE hTemplateFile);

bevor Fragen aufkommen:
Ja, dass soll C sein!
Nein, dass ist kein Scherz, dass steht wirklich so in der MSDN!
Ja, dass ist keine Ausnahme, sondern ein treffendes Beispiel.
Ja, es gibt noch schlimmere Funktionen, mit Parameter, die einfach reserviert für Erweiterungen sind und per default NULL sind.

und wenn wir schon bei absolut hirnrissigen Namenskonventionen sind, OpenGL hat das ja sogar bei den Funktionsnamen.

Und zu DirectX

BOOL InitDirectDraw(HWND hwnd) {
  LPDIRECTDRAW lpDDraw = NULL;
  if(DirectDrawCreate(NULL, &lpDDraw, NULL)!= DD_OK) {
    MessageBox(hwnd, "Konnte DirectDraw-Objekt nicht erzeugen.", NULL, MB_OK);   
    return FALSE;
  }
  if(lpDDraw->lpVtbl->QueryInterface(lpDDraw, &IID_IDirectDraw7, (void **)&lpDDraw7)!=DD_OK) {
    MessageBox(hwnd, "Keine Schnittstelle zu DirectDraw7 vorhanden", NULL, MB_OK);
    return FALSE;
  }
  lpDDraw->lpVtbl->Release(lpDDraw);
  //...

ja, dass ist die directX Art um C++ zu programmieren. Jemand, der nicht den ganzen Tag Crack nimmt hätte die Api wahrscheinlich so gebaut, dass man das gleiche, was da oben steht mit

DirectDraw ddraw(7,0);

erreichen kann.

Immer noch besser als etwas funktionsorientiertes dauernd wrappen zu müssen!

sag blos nicht, dass du dieses DirectX gewurschtel ungewrapped in deinem Code benutzt

[illuminator]

@kingruedi:
1. Hier DirectDraw7 Als Beipiel ranzuziehen ist unfair. Wir sind bei 9.

if( NULL != (D3D9 = Direct3DCreate9(D3D_SDK_VERSION)) )
    return true;

Als DirectDraw7 noch "in" war wollte MS halt die C Leute nicht vergraulen. Das kannst du ihnen nicht vorwerfen

HANDLE CreateFile(LPCTSTR lpFileName,DWORD dwDesiredAccess,DWORD dwShareMode, LPSECURITY_ATTRIBUTES lpSecurityAttributes,DWORD dwCreationDisposition,DWORD wFlagsAndAttributes,HANDLE hTemplateFile);

Was ist daran so schlimm? Welche Namenskonventionen stören dich denn so?

Ja, es gibt noch schlimmere Funktionen, mit Parameter, die einfach reserviert für Erweiterungen sind und per default NULL sind

Hat IMHO den Sinn, dass man das was anno dünnemals für Win2000 geschrieben wurde für Windows XP nicht ändern muss. Find ich sinnvoll.

Das die ganze Winapi C ist ist grundsätzlich sinnvoll, weil man so z.B. leicht aus anderen Programmiersprachen darauf zurückgreifen kann, z.B. VisualbBasic oder Delphi.
Wenn dir das nicht passt: Nimm die MFC.

[Kane]

Alte Programme sind
100%ig kompatibel, da alte DX Versionen generell erhalten bleiben.

Lol, ich würde dir so gerne glauben... Schon mal versucht ein älteres DirectX Spiel (Thief, System Shock 2, etc) zu spielen?
Klar es geht, aber der Software-Renderer von DX rockt nicht gerade und der
HAL-Renderer wurde aus platzgründen rausgenommen, tja...

Oder mal anderes gesagt, DX ist effektiv nur maximal 2 Versionen rückwärtskompatibel.

[illuminator]

Lol, ich würde dir so gerne glauben... Schon mal versucht ein älteres DirectX Spiel (Thief, System Shock 2, etc) zu spielen?
Klar es geht, aber der Software-Renderer von DX rockt nicht gerade und der
HAL-Renderer wurde aus platzgründen rausgenommen, tja...

Oder mal anderes gesagt, DX ist effektiv nur maximal 2 Versionen rückwärtskompatibel.

Tja komisch auf meinem Rechner mit WindowsXP und DirectX laufen sogar noch die alten DirectX6 Tutorials mit denn ich damals angefangen habe
Und das ich das letzte mal Thief und C&C Redalert (1. Teil, DirectX6) gezockt habe ist gar nicht solang her.

[rüdiger]

1. Hier DirectDraw7 Als Beipiel ranzuziehen ist unfair. Wir sind bei 9.

die Situation scheint sich aber nicht so besonders verbessert zu haben

Direct3DRMCreate(&lpD3DRM);
//...
lpD3DRM->CreateViewport(device, camera,
        0, 0, width, height, &view);
//...
view->Release();

*yuck* view->Release();

in vernünftigem C++ säh das ungefähr so aus:

direct3d d3drm;
viewport view(device,camerea,0,0,width,height,d3drm);
//...
// *schwups* wow, Release wurde durch einen Dtor ersetzt
// so muss man auch keinn Angst vor Exceptions mehr haben

Was ist daran so schlimm?

zu viele Parameter, dass macht die Funktion unübersichtlich. Vorallem da die meisten Parameter in 90% der Fälle eh mit Default Werten belegt werden und warum schaffen das andere APIs so eine Funktion ungefähr so hinzubekommen?

int creat(const char *pathname, mode_t mode);

find ich persönlich deutlich übersichtlicher.

Welche Namenskonventionen stören dich denn so?

a) komplett groß geschriebene Typnamen, dass ist absolut untypisch für C/C++
b) ungarische Notation. Aber das haben wir schon tausend mal diskutiert (wobei man bei übersichtlicheren Funktionen wahrscheinlich nie auf die Idee gekommen wär mit der UN)

Hat IMHO den Sinn, dass man das was anno dünnemals für Win2000 geschrieben wurde für Windows XP nicht ändern muss. Find ich sinnvoll.

Warum dann nicht FunktionA und wenn man unter WinXP die Funktion erweitert macht man FunktionAWinXP

Das die ganze Winapi C ist ist grundsätzlich sinnvoll, weil man so z.B. leicht aus anderen Programmiersprachen darauf zurückgreifen kann, z.B. VisualbBasic oder Delphi.

mir geht es nicht darum, dass die API in C ist

Wenn dir das nicht passt: Nimm die MFC.

klar, dann tausche ich eine hässliche C API durch eine hässliche C++ Wrapper API. Nein danke, da habe ich schon meine Favouriten, die auch gleich unter MacOSX und Linux laufen, so dass man nicht die Anwendung jedes mal neu schreiben muss

[TGGC]

Kane schrieb:

Schon mal versucht ein älteres DirectX Spiel (Thief, System Shock 2, etc) zu spielen?

Wir haben letztens erst StarCraft (DX5) gezockt. Problemlos.

Bye, TGGC (Zu viele Primitve hier.)

[otze]

direct3d d3drm;

imho wär das aber ein rückschritt, da so keine abwärtskompatibilität mehr möglich wäre, einfach deshalb, weil man die möglichkeit hat, die objekte hinter einem interface austauschen zu können->es würde für eine anwendung, die sich ihre objecte etc aus einer dll holt keinen unterschied machen, ob das objekt inhaltlich anders ist, hauptsache es ist mit dem interface kompatibel.

@kane bei mir läuft sogar noch might&magic6 und das stammt aus directX6(oder wars 5?) zeiten(ok, man muss scho was tricksen wegen winxp,aber es geht)

[energyzer]

Um mal wieder zum Thema zu kommen: Hat jemand weiter gehende Infos zum DX
Nachfolger?

z.B. Wann?

[illuminator]

kingruedi schrieb:

1. Hier DirectDraw7 Als Beipiel ranzuziehen ist unfair. Wir sind bei 9.

die Situation scheint sich aber nicht so besonders verbessert zu haben

Direct3DRMCreate(&lpD3DRM);
//...
lpD3DRM->CreateViewport(device, camera,
        0, 0, width, height, &view);
//...
view->Release();

*yuck* view->Release();

in vernünftigem C++ säh das ungefähr so aus:

direct3d d3drm;
viewport view(device,camerea,0,0,width,height,d3drm);
//...
// *schwups* wow, Release wurde durch einen Dtor ersetzt
// so muss man auch keinn Angst vor Exceptions mehr haben

Damit müsste M$ aber dann für alle anderen Programmiersprachen die DX unterstützen eine Extra-Interface mit komplett anderem Handling bieten.
Das C++ Klassenmodell, so wie du es Vorschlägst lässt sich nämlich nicht einfach überall intergrieren.
Im übrigen ist dein Code oben schon wieder DirectX 7

kingruedi schrieb:

Was ist daran so schlimm?

zu viele Parameter, dass macht die Funktion unübersichtlich. Vorallem da die meisten Parameter in 90% der Fälle eh mit Default Werten belegt werden und warum schaffen das andere APIs so eine Funktion ungefähr so hinzubekommen?

int creat(const char *pathname, mode_t mode);

find ich persönlich deutlich übersichtlicher.

Erzähl mir mal wie du deiner Funktion die z.B. Security Attributes mitgeben willst.

kingruedi schrieb:

[

Hat IMHO den Sinn, dass man das was anno dünnemals für Win2000 geschrieben wurde für Windows XP nicht ändern muss. Find ich sinnvoll.

Warum dann nicht FunktionA und wenn man unter WinXP die Funktion erweitert macht man FunktionAWinXP

sieht dann so aus oder wie?

#ifdef WINNT
    FunktionAWinNT( param1, param2);
#endif
#ifdef WIN2k
    FunktionAWin2k( param1, param2, param3);
#endif
#ifdef WINXP
    FunktionAWinXP( param1, param2, param3, param4);
#endif

Nein, danke. Dann hast du schon mehrere Binaries und noch dazu weisst du ja so im voraus nicht wie die Funktion unter WinXP aussieht wenn es noch nicht draußen ist.

[SideWinder]

kingruedi kennt das Problem nicht, seine Betriebssysteme werden nur in Versionen bis 0.4 ausgeliefert. Zu einer Alpha-Version reichen die Mittel nicht. Somit gibts auch nur eine System-Library die man nicht abwärtskompatibel halten muss.

*mad-Smilies kassieren geh lol*

MfG SideWinder

[dot]

lol, dass muss man nicht fragen, wenn man schon einmal mit der WinAPI gearbeitet hat. Die WinAPI ist ein riesiger undurchschauberer Brocken an unglaublich hässlichen C Funktionen mit einer absolut hirnrissigen Namenskonvention.

glaub mir, ich hab schon oft genug mit der WinAPI gearbeitet.

*yuck* view->Release();

in vernünftigem C++ säh das ungefähr so aus:

direct3d d3drm;
viewport view(device,camerea,0,0,width,height,d3drm);
//...
// *schwups* wow, Release wurde durch einen Dtor ersetzt
// so muss man auch keinn Angst vor Exceptions mehr haben

wenn du wüsstest was die drei buchstaben COM bedeuten, dann wüsstest du, warum es ->Release() gibt und keinen dtor.

oder zeig mir mal wie du deine wunderschöne C++ klasse mit dtor unter VisualBasic verwendest ohne sie in einer dll funktionsorientiert zu wrappen und dann erst wieder keinen dtor zu haben...

btw, welche angst vor welchen exceptions muss man nicht mehr haben, wenn man einen dtor anstatt von release verwendent!?

PS: ich hab WindowsXP mit DirectX 9.0b und Diablo läuft wie eh und je ( verwendet DirectX 3 )

[Sgt. Nukem]

Kane schrieb:

Alte Programme sind
100%ig kompatibel, da alte DX Versionen generell erhalten bleiben.

Lol, ich würde dir so gerne glauben... Schon mal versucht ein älteres DirectX Spiel (Thief, System Shock 2, etc) zu spielen?

Yupp, eben noch.

Baphomet's Fluch (DirectX 2!) auf Win95 unter DX 8.0a und unter WinXP unter DX 9.0b!

SideWinder schrieb:

kingruedi kennt das Problem nicht, seine Betriebssysteme werden nur in Versionen bis 0.4 ausgeliefert. Zu einer Alpha-Version reichen die Mittel nicht. Somit gibts auch nur eine System-Library die man nicht abwärtskompatibel halten muss.

*mad-Smilies kassieren geh lol*

MEGA-LOL

EDIT: BTW, ich kenne kein Spiel, welches DirectX 1 (GameSDK) verwendet...
Kennt einer eins? Würd's gern testen...

[TGGC]

Sgt. Nukem schrieb:

Kennt einer eins? Würd's gern testen...

Warum? Würde ehh gehen. DX felst.

Bye, TGGC (Zu viele Primitve hier.)

[Gast]

Ist doch nicht schwer, abzusehen, auf was das alles hinauslaufen soll. Wenn man ab und zu mal ein Interview mitkriegt, in der MSDN liest (oder auf Seminaren von M$ war), dann hört man so unglaubliche Sachen, wie das zukünftig alles (auch die neue System API) auf dem .Net Framework basieren soll (das schließt wohl DirectX mit ein).
Genauso wie Aussagen nach dem Motto (sinngemäß) "wer in Zukunft nicht auf managed Code setzt, hat ein echtes Problem".
Tja, ich hab kein Problem damit und managed DirectX ist btw. nach meiner Meinung sehr schön designt worden. Da reg ich mich gar nicht mehr über COM auf (Referenzzählung, pfui, garbage collection rult).

[TGGC]

Genau, lasst Microsoft machen. Das kann nur gut werden.

Bye, TGGC (Zu viele Primitve hier.)

[interpreter]

Optimizer schrieb:

M$

Ich kann es nicht mehr sehen...

[otze]

in dem moment wo managed code pflicht wird, formatier ich meinen pc und lern linux