Was kommt nach DirectX??

Babbo

@leech: AFAIK sobald longhorn kommt.
@Blue-Tiger: es gibt zwar viele APIs, aber ich habe immer noch keine gefunden, die DirectMusic ähnelt... oder kann SDL das auch? (ich meine den Kram mit MIDIs, DLSs, etc.) also nochmal an alle, kennt jemand so eine?
@TGGC naja, aber ich denke doch, dass ein "einfaches" update der api schon was anderes ist, als ein komplett neues OS. außerdem ist es ja nur möglich, DD noch zu nutzen, da COM abwärtskompatibel is (schlagt mich nicht, wenn das jetz irgendwie falschg formuliert ist), und davon geht ms ja schon mit managed directx weg.

Sgt. Nukem

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

Solange sie sich nicht an OpenGL's "Design" (WTF??) halten, ist alles in Butter!

spl*t

Sgt. Nukem schrieb:

Solange sie sich nicht an OpenGL's "Design" (WTF??) halten, ist alles in Butter!

Öh, was genau findest du daran so schlecht? Ok, es ist C und funktionsbasierend, viel Design ist auch nicht dabei, aber die Namen sind eindeutig und man kann sehr sauberen Code schreiben, und selber kapseln.

Naja, also so lange OGL-Progs noch laufen werden, bin ich zufrieden, und interessieren tut mich sowieso nur OGL 2.0.

Kane

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.

Ja ok, über das Extension Interface kann man sich streiten, aber da es eine Extension ist rechnen die meisten Programme damit dass das Feature NICHT da ist
und reagieren darauf.
In sofern finde ich diese Lösung besser da man von der Versionsnummer unabhängig ist.

Für GUI benutze ich sowieso nur noch Wrapper (wxWindows, früher Qt und Gtkmm),
die sind von der Benutztbarkeit meistens etwas angenehmer.

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