OpenGL mit neuen Konzepten

[Corrail]

http://www.opengl.org/news/permalink/advanced_visual_effects_with_opengl_report_from_gdc_opengl_21_arb_vista/

Endlich News über OpenGL! :biggrin: :biggrin: :biggrin:
Die neuen Konzepte hören sich echt gut an! *erstauntbin*

[Coda]

ARB_synch_objectSoll wohl eher ARB_sync_object heißen nehm ich mal an? :|

Ob das mit Vista aber wirklich auf Druck geschah und nicht sowieso vorgesehen war, da bin ich mir nicht ganz sicher...

[ScottManDeath]

Jo, wird auch Zeit. Da nun das Schiff* am Sinken ist verlassen die Ratten dieses und suchen sich einen neuen Dampfer ;) Guter Plan. Aber nun muss es noch umgesetzt werden, und zwar bald.


*SGI

[Asmodeus]

... Aber nun muss es noch umgesetzt werden, und zwar bald.
*SGI

Als "Release-Termin" von OpenGL 2.1 wird ja die Siggraph dieses Jahr angegeben, also Ende Juli. Somit sollten dann wohl bis Ende des Jahres die ersten Implementierungen in Treibern vorhanden sein können.

Gruss, Carsten.

[Demirug]

Als "Release-Termin" von OpenGL 2.1 wird ja die Siggraph dieses Jahr angegeben, also Ende Juli. Somit sollten dann wohl bis Ende des Jahres die ersten Implementierungen in Treibern vorhanden sein können.

Gruss, Carsten.

Das meiste was da steht bezieht sich aber auf eine 3.0 LM Version die noch nicht mal als Vorschlag eingereicht ist. Zudem erinnert mich das ganze massive an die Direct3D 10 API die ich gerade Zwegs portierung auf .Net Stück für Stück durcharbeite.

[ScottManDeath]

Das meiste was da steht bezieht sich aber auf eine 3.0 LM Version die noch nicht mal als Vorschlag eingereicht ist. Zudem erinnert mich das ganze massive an die Direct3D 10 API die ich gerade Zwegs portierung auf .Net Stück für Stück durcharbeite.


Jo, hab ich mir auch gedacht. Läuft ja auf der selben HW.

Portierung von D3D 10 auf .Net. Gibts noch keine ManagedD3D 10?

[Demirug]

Portierung von D3D 10 auf .Net. Gibts noch keine ManagedD3D 10?

Würde ich sonst meine eigene Version schreiben? Die managed DX Jungs (oder sagen wir besser Tom Miller) muss sich ja jetzt erstmal um den XNA Framwork kümmern. Da die managed Versionen ja auf den unmanaged aufbauen wird man zudem wohl abwarten wollen ob sich da noch etwas ändert. Mit C++/CLR geht das aber viel besser als damals mit managed C++ wo ich schonmal angefangen einen Managed DX 8 layer zu schreiben. Vorallem mit den generics can man böse sache machen. Typisierte Date Buffer sind eine feine Sache

SimpleVertex[] vertices = new SimpleVertex[]
{
new SimpleVertex (new D3D10.Vector3 ( 0.0f, 0.5f, 0.5f)),
new SimpleVertex (new D3D10.Vector3 ( 0.5f,-0.5f, 0.5f)),
new SimpleVertex (new D3D10.Vector3 (-0.5f,-0.5f, 0.5f))
};

vertexBuffer = new D3D10.Generic.Buffer<SimpleVertex>
(
device,
D3D10.Usage.Default,
D3D10.BindFlag.VertexBuffer,
D3D10.CPUAccessFlag.None,
D3D10.ResourceMiscFlag.None,
vertices
);

[ScottManDeath]

Cool =)

Ich hatte mal drüber nachgedacht, mit Attributen auf den Vertex Struct Membern automatisch die Vertex Shader Deklarationen zu generieren.

[Demirug]

Cool =)

Ich habe noch mehr so Dinge drin. -> http://www.gamedev.net/community/forums/topic.asp?topic_id=382892

Ich hatte mal drüber nachgedacht, mit Attributen auf den Vertex Struct Membern automatisch die Vertex Shader Deklarationen zu generieren.

Die Idee ist nicht schlecht. Man könnte das sicherlich sogar noch so erweitern das er wenn keine Attribute vorhanden sind aus den Datentype der Vertex struct die nötigen Werte ableitet. Bei D3D10 nennt sich das BTW jetzt InputLayout.

Aber wir sind offtopic.

[ScottManDeath]

Eine offizielle Managed OpenGL API wäre auch nicht schlecht. Für das böse Jot-Wort gibts das ja schon ;) Tao geht schon, das ist aber auch nur ein 1:1 Mapping. Mit einem fikitiven OpenGL LM wäre ein Mapping auf Klassen doch einfacher, da das ganze Bindien wegfiele und man den "this" Pointer bei jedem Call mitübergeben muss.

Hoffentlich haben sie Arsch genug in der Hose, das auch umzusetzen. 3DLabs ist ja 2001 mit ihrem OpenGL 2.0 auch nicht weiter gekommen :(

Das gleiche könnte man auch für Managed OpenGL machen und automatisch die Vertexpointer, Strides, Offsets automatisch bestimmen.


Problematisch wirds nur, wenn man seine Vertexdaten auf mehrere Buffer mit unterschiedlichen Datentypen verteilt, dann ist das Mapping nicht unbedingt eindeutig :confused: Man könnte auch aus den Membernamen die Semantik ableiten...

[Demirug]

Hoffentlich haben sie Arsch genug in der Hose, das auch umzusetzen. 3DLabs ist ja 2001 mit ihrem OpenGL 2.0 auch nicht weiter gekommen :(

Da wohl ATI und nVidia dahinter stehen steigt die Wahrscheinlichkeit.

Das gleiche könnte man auch für Managed OpenGL machen und automatisch die Vertexpointer, Strides, Offsets automatisch bestimmen.


Problematisch wirds nur, wenn man seine Vertexdaten auf mehrere Buffer mit unterschiedlichen Datentypen verteilt, dann ist das Mapping nicht unbedingt eindeutig :confused: Man könnte auch aus den Membernamen die Semantik ableiten...

Dann müsste mantürlich ein Array von VertexStrukture Typen übergeben. Bei D3D10 ist das mit der Semantik kein Problem mehr weil es frei wählbare Strings sind. Da könnte man dann einfach die member namen wählen und wenn die Doppelt sind geht es eben einfach nicht -> Exception

[eXistence]

As mentioned previously, because of developer and IHV action, OpenGL ICDs will be fully supported under Windows Vista


Soll das bedeuten, dass die Unklarheiten über die Zukunft von OpenGL unter Vista endgültig vom Tisch sind?
Ich habs nur am Rande verfolgt, aber gabs da nicht mal Gerüchte, dass OpenGL entweder nur eingeschränkt zusammen mit der neuen Oberfläche funktioniert oder über DX gewrappt werden muss?

[Gast]

Soll das bedeuten, dass die Unklarheiten über die Zukunft von OpenGL unter Vista endgültig vom Tisch sind?
Ich habs nur am Rande verfolgt, aber gabs da nicht mal Gerüchte, dass OpenGL entweder nur eingeschränkt zusammen mit der neuen Oberfläche funktioniert oder über DX gewrappt werden muss?

3D-anwendungen im fenster funktionieren mit der neuen oberfläche nicht gemeinsam. das gilt für D3D9 ung OGL gleichermaßen.

wird eine entsprechende anwendung gestartet, dann beendet vista automatisch den 3D-desktop und schaltet auf die 2D-version zurück. wird die 3D-anwendung wieder beendet schaltet vista dann auch wieder den 3D-desktop ein.

[Corrail]

3D-anwendungen im fenster funktionieren mit der neuen oberfläche nicht gemeinsam. das gilt für D3D9 ung OGL gleichermaßen.

wird eine entsprechende anwendung gestartet, dann beendet vista automatisch den 3D-desktop und schaltet auf die 2D-version zurück. wird die 3D-anwendung wieder beendet schaltet vista dann auch wieder den 3D-desktop ein.

Kann das jemand bestätigen/dementieren? Ich habe das anders in Erinnerung...

[Asmodeus]

3 Pfade sind für OpenGL unter Vista vorgesehen:


...
OpenGL can go through one of three paths in Windows Vista depending on how your computer is configured.

1. MSOGL - this is an implementation of OpenGL 1.4 that uses Direct3D under the covers to hardware accellerate the application.

2. Legacy ICD's - These are the ICD's that are available today for use on Windows XP. These will continue to work on Windows Vista, but will disable the DWM when they are loaded in to the process of the application that's using OpenGL. The reason for this is that Legacy ICD's operate directly on the GPU without going through Windows at all, and we have no way of redirecting application's output in a stable, predictable manner.

3. Windows Vista ICD's - this is a new path for 3rd party ICD's introduced for Windows Vista that will work in a way that is compatible with desktop composition. Essentially allowing direct access to the GPU for hardware accellaration, but then having the final surface that appears to be the front buffer to the application actually be a shared surface that gets composed by the DWM



Gruss, Carsten.

[Demirug]

3D-anwendungen im fenster funktionieren mit der neuen oberfläche nicht gemeinsam. das gilt für D3D9 ung OGL gleichermaßen.

wird eine entsprechende anwendung gestartet, dann beendet vista automatisch den 3D-desktop und schaltet auf die 2D-version zurück. wird die 3D-anwendung wieder beendet schaltet vista dann auch wieder den 3D-desktop ein.

Mit D3D9 ging das schon die ganze Zeit weil D3D9 keinen direkten Zugriff auf den Front Buffer erlaubt.

Mit OpenGL gab es das Problem das es grundsätzlich Funktionen dafür gibt und Microsoft selbst nicht feststellen kann wann es dazu kommt. Scheinbar hat man jetzt in das OpenGL ICD DDK eine Funktion eingebaut mit der die IHVs melden können wenn sie auf den Frontbuffer zugreifen damit man die Desktop Engine deaktivieren kann.

[eXistence]

Wird OpenGL denn im Fenster funktionieren, wenn man den neuen Desktop abschaltet (und quasi mit dem alten arbeitet, sofern das geht...)?

Mit stellt sich nämlich diese Frage, da ich viel mit Maya und ähnliches Progs arbeite, und die meisten verwenden (noch?) OpenGL zur Darstellung....

[Expandable]

Die Features, die nVidia/ATi vorgeschlagen haben, klingen aber ganz gut... OpenGL zu entschlacken kann eigentlich nicht schaden... Nur fand ich persönlich die Objekt-Sache in OpenGL schön gelöst. Schade, wenn man da jetzt mit Pointer anfangen muss. Dann wäre "richtige" Objekt-Orientierung (also mit C++-Klassen) doch besser, fände ich.

[Demirug]

Die Features, die nVidia/ATi vorgeschlagen haben, klingen aber ganz gut... OpenGL zu entschlacken kann eigentlich nicht schaden... Nur fand ich persönlich die Objekt-Sache in OpenGL schön gelöst. Schade, wenn man da jetzt mit Pointer anfangen muss. Dann wäre "richtige" Objekt-Orientierung (also mit C++-Klassen) doch besser, fände ich.

Also mir hat das binden nie gefallen und man sollte die Pointer einfach als Handles sehen.

Das Problem mit echtem OO ist das es nicht von jeder Sprache unterstützt wird. Man kann zwar sowas wie COM auch mit C Bindings nutzen aber das wird tendenziel hässlich.

[Demirug]

Wird OpenGL denn im Fenster funktionieren, wenn man den neuen Desktop abschaltet (und quasi mit dem alten arbeitet, sofern das geht...)?

Mit stellt sich nämlich diese Frage, da ich viel mit Maya und ähnliches Progs arbeite, und die meisten verwenden (noch?) OpenGL zur Darstellung....

1. Den Desktop braucht man nie selbst abzuschalten das macht Vista von aleine sobald eine Applikation eine kritische Funktion ausführt. Nachdem diese Applikation beendet wurde startet sich der Desktop wieder.

2. OpenGL im Fenster war nie ein Problem.

3. Hat man einen neuen Vista ICD kann man OpenGL im Fenster zusammen mit dem neuen Desktop benutzten solange die App sonst nichts böses tut.

[Benedikt]

Managed DirectX: Wieviel performance kostet das, wenn man's einsetzt? Ich meine, da wird doch wieder eine Zwischenschicht zwischen Anwendung und HW eingezogen, oder? Kostet es überhaupt Performance?

[Coda]

Der DX9-Overhead auf Windows XP ist so auch schon schlimm genug, da wird das wohl kaum ins Gewicht fallen.

[Gast]

Das meiste was da steht bezieht sich aber auf eine 3.0 LM Version die noch nicht mal als Vorschlag eingereicht ist. Zudem erinnert mich das ganze massive an die Direct3D 10 API die ich gerade Zwegs portierung auf .Net Stück für Stück durcharbeite.Die Realitaet ist dass sich D3D immer weiter in Richtung OGL entwickelt hat (state engine, etc.).
Die meisten Konzepte vom heutigen und kommenden D3D wurden von OGL einfach abgekupfert.

Auch D3D10 wird OGL in Sachen Leichtfuessigkeit WEIT hinterherhinken.
Man braucht sich nur mal die Argumentlisten fuer D3D Methoden anschauen.
Da bekomme ich schon vom hinschauen einen Fingerkrampf.
Ich glaube auch nicht dass D3D10 den _enormen_ Effizienzunterschied in Szenen mit vielen draw batches aufholen kann.
Das liegt nicht nur an der API-Anbindung.


Achja: Es war absolut nicht selbstverstaendlich fuer MS dass OGL ICDs direkten Hardwarezugriff bekommen sollten!
Das bewiesen schon alleine die fruehen Vista Architektur-previews.

[Coda]

Die Realitaet ist dass sich D3D immer weiter in Richtung OGL entwickelt hat (state engine, etc.).
Die meisten Konzepte vom heutigen und kommenden D3D wurden von OGL einfach abgekupfert.Richtig.

Auch D3D10 wird OGL in Sachen Leichtfuessigkeit WEIT hinterherhinken.Dummfug. Du solltest dir mal die Dokumentation anschauen.

Man braucht sich nur mal die Argumentlisten fuer D3D Methoden anschauen.
Da bekomme ich schon vom hinschauen einen Fingerkrampf.Auch Dummfug. Die Funktionen unterscheiden sich im Prinzip nur noch durch das zusätzliche COM-Handle das man braucht

Ich glaube auch nicht dass D3D10 den _enormen_ Effizienzunterschied in Szenen mit vielen draw batches aufholen kann.
Das liegt nicht nur an der API-Anbindung.Doch genau daran liegt es. Selbst DX9 hat unter Vista den Overhead nicht mehr.

[Gast]

Dummfug. Du solltest dir mal die Dokumentation anschauen.
Auch Dummfug. Die Funktionen unterscheiden sich im Prinzip nur noch durch das zusätzliche COM-Handle das man braucht"Dummfug" ... soso.
Na wenn du meinst dass D3D im Vergleich zu OGL keinen deutlich hoeherer Syntaxaufwand hat...
Ist schon abenteuerlich diese eigentlich unumstrittene Behauptung als "Dummfug" hinzustellen.

Doch genau daran liegt es. Selbst DX9 hat unter Vista den Overhead nicht mehr.Der batch-Durchsatz relativ zur batch-Groesse verlaeuft bei D3D linear, bei OGL jedoch proportional. Der Unterschied ist also eindeutig algorithmisch begruendet.
Ich habe bei Vergleichstests in komplexen Szenen einen Leistungsunterschied bis zum Faktor 3 (zugunsten OGL) gemessen.

[Gast]

kleine Korrektur:

Die Relation bei OGL ist natuerlich umgekehrt proportional.
Natuerlich verhaelt sich D3D dabei qualitativ betrachtet auch umgekehrt proportional, allerdings mit einer voellig anderen Differentialgroessenordnung.
Und das offenbart die bereits genannte algorithmische Ursache fuer den Leistungsunterschied.

[Coda]

"Dummfug" ... soso.
Na wenn du meinst dass D3D im Vergleich zu OGL keinen deutlich hoeherer Syntaxaufwand hat...
Ist schon abenteuerlich diese eigentlich unumstrittene Behauptung als "Dummfug" hinzustellen.Jo weil es einfach so ist. Meine Engine hat sowohl ein D3D- als auch ein OpenGL-Backend und der Unterschied ist minimal. Wer sich wirklich an direct3ddevice->DrawIndexedPrimitive vs. glDrawElements aufhält ist nicht mehr ganz bei Trost (die Engine bei der das den Entwicklungsaufwand beeinflusst dürfte man wohl gar nicht so bezeichnen)

OpenGL ist durch den ganzen Extension-Schranz auch nicht wirklich schön.

Wenn du einen Vergleich willst schau dir Ogre3D an, da gibts auch sowohl OpenGL- und Direct3D9-Backends und iirc ist der OpenGL-Code sogar größer.

Der batch-Durchsatz relativ zur batch-Groesse verlaeuft bei D3D linear, bei OGL jedoch proportional. Der Unterschied ist also eindeutig algorithmisch begruendet.
Ich habe bei Vergleichstests in komplexen Szenen einen Leistungsunterschied bis zum Faktor 3 (zugunsten OGL) gemessen.Ja. Aber nicht unter Vista. Das ganze komische alte Treibermodell mit den internen Command-Buffers wurde dort über Bord geworfen.

[Gast]

Minimal ist nicht steigerbar.


Q

[Demirug]

Die Realitaet ist dass sich D3D immer weiter in Richtung OGL entwickelt hat (state engine, etc.).
Die meisten Konzepte vom heutigen und kommenden D3D wurden von OGL einfach abgekupfert.

State engine? D3D nutzt schon seit der ersten Version eine State engine. Wenn sie auch etwas umständlich zu programmieren war. Ansonsten haben sich OpenGL und D3D eben mit der Hardware mitentwickelt entsprechend hatte da immer mal einer die Nase vorn wenn es um einzelne Features geht. Ist ja auch nicht verwunderlich wenn bei beiden APIs im wesentlichen die gleichen Firmen mitreden.

Auch D3D10 wird OGL in Sachen Leichtfuessigkeit WEIT hinterherhinken.
Man braucht sich nur mal die Argumentlisten fuer D3D Methoden anschauen.
Da bekomme ich schon vom hinschauen einen Fingerkrampf.

Ansichtsache. Ich empfinde die C API von OpenGL als grausam.

Ich glaube auch nicht dass D3D10 den _enormen_ Effizienzunterschied in Szenen mit vielen draw batches aufholen kann.
Das liegt nicht nur an der API-Anbindung.

An was den sonst? Gerade bei den Draw Batches macht die Runtime von D3D nichts ausser der API Anbindung.

Achja: Es war absolut nicht selbstverstaendlich fuer MS dass OGL ICDs direkten Hardwarezugriff bekommen sollten!
Das bewiesen schon alleine die fruehen Vista Architektur-previews.

Welche Architektur Previews? WinHEC, DDKs? Dem geneigten Leser sei empfohlen sich das erste Vista (damals noch Longhorn) DDK zu besorgen und sich dort nach der OpenGL Treiber Einbindung umzuschauen. Dort wird nämlich beschrieben wie sich ein OpenGL ICD in das neue Treibermodel einfügt.

[Chris Lux]

opengl lebt doch noch. am interessantesten finde ich, dass das management an die khronos gruppe gegeben wird. mal sehen wie es da nun weitergeht.

quelle:
http://www.gamedev.net/columns/events/gdc2006/article.asp?id=233

[Bokill]

Macht weiter! :)

Prima Diskussion, auch wenn ich selber 0% Inhalt anbieten kann. Mit genau diesen Threads mag ich 3DC und bestimmte Member und auch Gäste ...

MFG Bobo(2006)

[ScottManDeath]

Jo, ich mach nun seit 5+ Jahren OpenGL und finde das die Direct3D API seit D3D 9 immmer mehr an Sex-Appeal zulegt. D3D10 macht mich da ganz schön rattig ;)

Schlanke, OO Architektur, eine überschaubare Anzahl an Klassen, unter .Net nicht mal mehr das hässliche COM, was will man mehr?

Jetzt muss ich bloß noch den inneren Schweinehund überwinden endlich mal was größeres in D3D zusammenbauen :redface:


Der Overhead von .Net zu Native ist in GPU limitierten Szenarien nicht das ausschlaggebende. Wenn man allerdings viel Gleitkommaberechnungen macht, dann ist C# nicht so der Überflieger, ich weiß allerdings nicht, wie sich der C++/CLI Compiler im Vergleich dazu verhält.

Mal sehen, wenn ich im Sommer* bei den kleinen grünen Männchen an der Westküste bin, vielleicht muss ich dann D3D machen ;)




* Juhu, noch 6 Wochenn bis dahin

[Demirug]

Jo, ich mach nun seit 5+ Jahren OpenGL und finde das die Direct3D API seit D3D 9 immmer mehr an Sex-Appeal zulegt. D3D10 macht mich da ganz schön rattig ;)

Schlanke, OO Architektur, eine überschaubare Anzahl an Klassen, unter .Net nicht mal mehr das hässliche COM, was will man mehr?

Bei D3D10 gab es aber eine regelrechte Interfaceexplosion und bei einer Managed Version werden es noch mehr sein weil man einige Hilfsklassen braucht.

[ScottManDeath]

Bei D3D10 gab es aber eine regelrechte Interfaceexplosion und bei einer Managed Version werden es noch mehr sein weil man einige Hilfsklassen braucht.

Sagen wir es mal so: mein Raytracer hat 160 Klassen ;) Tendenz steigend ;)

[micki]

ich arbeite seit xyz-jahren mit ogl und seit xy-jahren mit d3d und finde es lächerlich, dass sogar die gurus hier ihre flames loswerden müssen, jeder der vernünftig eine api nutzt schreibt sich einen wrapper drum und arbeitet nicht auf nacktem zahnfleisch. dann ist es auch absolut egal ob d3d oder ogl, egal ob c oder c++, es gibt keinen grund sich an sowas zu klammern, darunter ist der selber treiber, die selbe hardware... und wer es nicht kann oder wem es zuviel arbeit ist, nimmt sich irgend einen opensource wrapper z.b. von der Nebula engine.

[ScottManDeath]

ich arbeite seit xyz-jahren mit ogl und seit xy-jahren mit d3d und finde es lächerlich, dass sogar die gurus hier ihre flames loswerden müssen, jeder der vernünftig eine api nutzt schreibt sich einen wrapper drum und arbeitet nicht auf nacktem zahnfleisch. dann ist es auch absolut egal ob d3d oder ogl, egal ob c oder c++, es gibt keinen grund sich an sowas zu klammern, darunter ist der selber treiber, die selbe hardware... und wer es nicht kann oder wem es zuviel arbeit ist, nimmt sich irgend einen opensource wrapper z.b. von der Nebula engine.

Klar, ein eigener Wrapper ist sowieso das Beste. Allerdings lässt sich sowas IMHO leichter implementieren, wenn die unterliegende API OO ist.

[micki]

Klar, ein eigener Wrapper ist sowieso das Beste. Allerdings lässt sich sowas IMHO leichter implementieren, wenn die unterliegende API OO ist.
wie gesagt, wem diese kleine hürde schon probleme bereitet, kann einen fertigen nutzen... aber ich bezweifle, dass solche personen dann die skills haben, um die wirklich aufwendigen dinge zu implementieren.

[marco42]

Klar, ein eigener Wrapper ist sowieso das Beste. Allerdings lässt sich sowas IMHO leichter implementieren, wenn die unterliegende API OO ist.

Eigentlich hat OpenGL schon ein oder bessere zwei Objektmodelle. Der Binding Mechanismus war ja damals ganz elegant, da nicht alle Texturefunktionen neu geschrieben werden mussten. Aber es erschwert IMHO einen Wrapper zu schreiben. Wenn man jedesmal ein Objekt binden muss um seinen Parameter zu aendern, dann ist das IMHO nicht sehr schoen. Das Objektmodell der Shader ist da wesentlich besser und wenn ich den Artikel richtig verstanden habe, wollen sie das auch uebernehmen. Was mich ehrlich gesagt wundert, da da sie bei FBOs doch wieder zum alten Binding Mechanismus gegriffen haben.

[Corrail]

ATI hat die GDC06 Präsentation online gestellt
http://www.ati.com/developer/gdc/2006/GDC06-OpenGL_Tutorial_Day-Hart-OpenGL_03_Performance.pdf

[EDIT] hat nix mit OpenGL 3 zu tun... :(

[Benedikt]

Bei D3D10 gab es aber eine regelrechte Interfaceexplosion und bei einer Managed Version werden es noch mehr sein weil man einige Hilfsklassen braucht.
Eine Frage, die mich sehr interessiert: Gibts eigentlich jetzt schon richtig "große" Sachen, die unter Managed DX laufen (Spiele o. a.)?

Und, ich entschuldige vorab mein Newbie-Knowhow: Managed DirectX läuft in der CLR, ja? Oder hat das mit JIT-Compiling erst mal gar nichts zu tun, sondern ist nur ein anderer "Programmieransatz" (weiß auch nicht, wie ich das ausdrücken soll)?

[Demirug]

Eine Frage, die mich sehr interessiert: Gibts eigentlich jetzt schon richtig "große" Sachen, die unter Managed DX laufen (Spiele o. a.)?

Ich weiß das der Nachfolger von Arena Wars managed DirectX nutzen wird. Arena Wars ist zwar schon managed aber OpenGL weil es damals noch kein managed DirectX gab. Die meiste managed DX Software die es zur Zeit gibt wirst du wahrscheinlich nie zu Gesicht bekommen. Hauptsächlich wird es derzeit für interne Tools eingesetzt weil die Entwicklunggeschwindigkeit höher ist. Ein anderes Projekt das ich kenne nutzt managed DirectX für die echtzeit bearbeitung von Bildern die von einem Mikroskop kommen.

Und, ich entschuldige vorab mein Newbie-Knowhow: Managed DirectX läuft in der CLR, ja? Oder hat das mit JIT-Compiling erst mal gar nichts zu tun, sondern ist nur ein anderer "Programmieransatz" (weiß auch nicht, wie ich das ausdrücken soll)?

Managed DirectX läuft in der CLR. Im Prinzip wurden dabei einfach die DirectX Interfaces in .Net Objekte gekapselt.

[ScottManDeath]

War nicht auch Alexander der Große .NET und hat nicht Chrome für die Spiellogik das pöse Jot-Wort verwendet ;)

[micki]

ja es gab mehrere spiele die java als scriptengine verwendet haben. für scripten sind diese scriptsprachen gut, besonders, wenn man sie später in bytecode umwandeln kann (aus coder sicht)
wobei es ein wenig zu übertrieben bzw aufwändig ist mit java bzw c# zu scripten, weil scriptsprachen eben nicht für coder sein sollten, sondern für leute die aufgaben erledigen für die coder keine lust haben bzw. keine zeit, scripten eben. dazu zählt, dass man sich nicht über datentypen gedanken machen soll, ansonsten ist java/c# mit den ganzen arschabwischerchen eigentich super für einsteiger, ich kenne viele die früher VB (manche auch delphi) genutzt haben und nun c# nutzen, weil sie mit anderen sprachen die ihnen nicht für alles ne lib boten und keine gui(integration) hatten nicht arbeiten wollten, auch manche die auf java schworen, coden nun c# weil sie ihr geliebtes mono haben.

naja, an den programmen hat sich aber leider weiter nichts geändert, sie ziehen manchmal unglaublich viel speicher, stürzen nicht ab, sondern machen wundersame dinge, sind aber natürlich auch von nicht so super bezahlten leuten schnell gemacht, für interne zwecke ist das völlig ausreichend finde ich, man ärgert sich zwar öfters über den scheiss der damit passiert, ist aber relativ glücklich darüber, dass man das nicht coden mußte *hehe*.
ich nutze auch oft scriptsprachen um mir prototypen zu bauen bevor ich sie dann sauber implementiere. (profan des öfteren :D )

[Benedikt]

Hm, ich mag einfach noch nicht glauben, dass ein Spiel auf Managed DX-Basis (in der .net-runtime laufend) nicht mehr Ressourcen braucht, als ein "konventionell" unter C/C++ und DirectX geproggtes Spiel, und dabei auch noch gleich schnell läuft...
Meine Erfahrungen mit normalen .net-Anwendungen bestätigen einfach erhöhten Ressourcenverbrauch und zähere Ausführung (MeGui, das ATI-Controlpanel, Cuttermaran, Paint.net). Besonders an der Startgeschwindigkeit merkt man's IMO.

[TheGamer]

Soll wohl eher ARB_sync_object heißen nehm ich mal an?


Warum?

Hier wurde halt die Abkuerzung von synchronize um einen Buchstaben erweitert

[Coda]

Ich hab noch nirgends "synch" als Abkürzung für synchronize gesehen. Aber nun gut, sein könnte es X-D

[tokugawa]

Hm, ich mag einfach noch nicht glauben, dass ein Spiel auf Managed DX-Basis (in der .net-runtime laufend) nicht mehr Ressourcen braucht, als ein "konventionell" unter C/C++ und DirectX geproggtes Spiel, und dabei auch noch gleich schnell läuft...
Meine Erfahrungen mit normalen .net-Anwendungen bestätigen einfach erhöhten Ressourcenverbrauch und zähere Ausführung (MeGui, das ATI-Controlpanel, Cuttermaran, Paint.net). Besonders an der Startgeschwindigkeit merkt man's IMO.

Naja. Bei Grafikanwendungen ist der Bottleneck oft auf der GPU - wenn du es gscheit programmierst kannst du die Latenz verstecken (GPU und CPU laufen ja quasi asynchron).

Es ist also "in der Realität" möglich. Man muß nur höllisch aufpassen. Dass es natürlich exemplarisch (das wird sogar die Mehrheit sein) .NET Programme gibt die eben erhöhten Resourcenverbrauch und/oder zähere Ausführung haben, ist klar.

Wobei das mit der zäheren Ausführung sich in der Regel auf das Starten bezieht, während es läuft (und das ist das wichtige) hab ich auch bei deinen erwähnten Programmen keinen echten Unterschied gemerkt - im Gegenteil: im Vergleich zu Java GUIs (awt/Swing) bedient sich etwa Paint.NET richtig flüssig - nicht weniger flüssig als das Original-Paint.

Ach ja, das Demo "Bananarama" auf der folgenden Seite ist ein Grafikdemo, das auf C# programmiert wurde:
http://www.cg.tuwien.ac.at/courses/Realtime/HallOfFame/2005/index.html

Weiters gibt es schon einige Spiele die mit C# Grafikengines arbeiten, etwa Punch'n'Crunch:
http://www.punch-n-crunch.com/

Also, .NET hat sich auch in der Grafikprogrammierung in der Praxis durchaus bewiesen.