OpenGL Extension Viewer

[Exxtreme]

Scheint sehr interessant zu sein, das Programm:

http://www.rage3d.com/board/showthread.php?s=&threadid=33703024

[Endorphine]

Hmm, was kann das Programm denn besser als GLInfo2 (http://www.delphi3d.net/)? Das verwende ich, seit ich's mal bei ow gesehen habe. Mehr als alle Fähigkeiten ausgeben kann der OGL-Extension-Viewer bestimmt auch nicht ;)


Driver version 6.14.10.3842
Vendor ATI Technologies Inc.
Renderer RADEON 9700 x86/SSE2
OpenGL version 1.3.3842 WinXP Release

Extension lists
Extensions
GL_ARB_multitexture
GL_EXT_texture_env_add
GL_EXT_compiled_vertex_array
GL_S3_s3tc
GL_ARB_depth_texture
GL_ARB_fragment_program
GL_ARB_multisample
GL_ARB_point_parameters
GL_ARB_shadow
GL_ARB_shadow_ambient
GL_ARB_texture_border_clamp
GL_ARB_texture_compression
GL_ARB_texture_cube_map
GL_ARB_texture_env_add
GL_ARB_texture_env_combine
GL_ARB_texture_env_crossbar
GL_ARB_texture_env_dot3
GL_ARB_texture_mirrored_repeat
GL_ARB_transpose_matrix
GL_ARB_vertex_blend
GL_ARB_vertex_program
GL_ARB_window_pos
GL_ATI_draw_buffers
GL_ATI_element_array
GL_ATI_envmap_bumpmap
GL_ATI_fragment_shader
GL_ATI_map_object_buffer
GL_ATI_separate_stencil
GL_ATI_texture_env_combine3
GL_ATI_texture_float
GL_ATI_texture_mirror_once
GL_ATI_vertex_array_object
GL_ARB_vertex_buffer_object
GL_ATI_vertex_attrib_array_object
GL_ATI_vertex_streams
GL_ATIX_texture_env_combine3
GL_ATIX_texture_env_route
GL_ATIX_vertex_shader_output_point_size
GL_EXT_abgr
GL_EXT_bgra
GL_EXT_blend_color
GL_EXT_blend_func_separate
GL_EXT_blend_minmax
GL_EXT_blend_subtract
GL_EXT_clip_volume_hint
GL_EXT_draw_range_elements
GL_EXT_fog_coord
GL_EXT_multi_draw_arrays
GL_EXT_packed_pixels
GL_EXT_point_parameters
GL_EXT_rescale_normal
GL_EXT_secondary_color
GL_EXT_separate_specular_color
GL_EXT_stencil_wrap
GL_EXT_texgen_reflection
GL_EXT_texture3D
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_edge_clamp
GL_EXT_texture_env_combine
GL_EXT_texture_env_dot3
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod_bias
GL_EXT_texture_object
GL_EXT_texture_rectangle
GL_EXT_vertex_array
GL_EXT_vertex_shader
GL_HP_occlusion_test
GL_NV_texgen_reflection
GL_NV_blend_square
GL_NV_occlusion_query
GL_SGI_color_matrix
GL_SGIS_texture_edge_clamp
GL_SGIS_texture_border_clamp
GL_SGIS_texture_lod
GL_SGIS_generate_mipmap
GL_SGIS_multitexture
GL_SUN_multi_draw_arrays
GL_WIN_swap_hint
WGL_EXT_extensions_string
WGL_EXT_swap_control
WGL extensions WGL_ARB_extensions_string
WGL_ARB_make_current_read
WGL_ARB_multisample
WGL_ARB_pbuffer
WGL_ARB_pixel_format
WGL_ARB_render_texture
WGL_ATI_pixel_format_float
WGL_EXT_extensions_string
WGL_EXT_swap_control

Implementation specifics
Various limitations
Max. texture size 2048 x 2048
Max. number of light sources 8
Max. number of clipping planes 6
Max. pixel map table size 65536
Max. display list nesting level 64
Max. evaluator order 30
Point size range 1,000 to 64,000
Point size granularity 0,125
Line width range 1,000 to 64,000
Line width granularity 0,125
Maximum stack depths
Modelview matrix stack 32
Projection matrix stack 10
Texture matrix stack 10
Name stack 128
Attribute stack 16
Framebuffer properties
Sub-pixel precision bits 4
Max. viewport size 4096 x 4096
Number of auxiliary buffers 0

Extension specifics
Multitexture
Texture units 8
Texture compression
Supported formats DXT1 RGB DXT1 RGBA DXT3 RGBA DXT5 RGBA
Cubic env. mapping
Max. cube map texture size 2048
Anisotropic filtering
Max. anisotropy 16
3D texturing
Max. 3D texture size 2048 x 2048 x 2048
DrawRangeElements
Max. recommended index count 65535
Max. recommended vertex count 2147483647
Vertex blend
Max. vertex units 4
NV_occlusion_query
Pixel counter bits 32
ATI_vertex_streams
Max. vertex streams 2
Vertex shaders
Max. instructions 65535
Max. variants 32
Max. invariants 65535
Max. local constants 65535
Max. locals 65535
Max. optimized variants 17
Max. optimized invariants 256
Max. optimized local constants 256
Max. optimized locals 32
ATI_envmap_bumpmap
Bump texture units 32
ARB_vertex_program
Max. instructions 65535
Max. native instructions 256
Max. temporaries 65535
Max. native temporaries 32
Max. parameters 256
Max. native parameters 256
Max. attribs 32
Max. native attribs 18
Max. address registers 1
Max. native address registers 1
Max. local parameters 256
Max. env. parameters 256
Max. vertex attribs 256
Max. matrices 32
Max. matrix stack depth 16
ARB_fragment_program
Max. texture coords 8
Max. texture image units 16
Max. env. parameters 32
Max. local parameters 32
Max. matrices 32
Max. matrix stack depth 16
Max. instructions 128
Max. ALU instructions 96
Max. texture instructions 32
Max. texture indirections 7
Max. temporaries 32
Max. parameters 32
Max. attribs 10
Max. native instructions 96
Max. native ALU instructions 64
Max. native texture instructions32
Max. native texture indirections4
Max. native temporaries 32
Max. native parameters 32
Max. native attribs 10

[JTHawK]

Das Lustige am OGL Extension Viewer ist zb das man sehen kann welche OGL Spezifikation den nun ganz oder teilweise unterstützt wird. Sehr interessant :D

[aths]

Original geschrieben von JTHawK
Das Lustige am OGL Extension Viewer ist zb das man sehen kann welche OGL Spezifikation den nun ganz oder teilweise unterstützt wird. Sehr interessant :D Japp, das rockt! 1.4 wird bei mir zu 92% supportet, 1.5 zu 50%, bis 1.3 wird alles unterstützt.


Weiß jemand, was GL_EXT_blend_func_seperate macht?

[mapel110]

Original geschrieben von aths
Japp, das rockt! 1.4 wird bei mir zu 92% supportet, 1.5 zu 50%, bis 1.3 wird alles unterstützt.


Weiß jemand, was GL_EXT_blend_func_seperate macht?

http://oss.sgi.com/projects/ogl-sample/registry/EXT/blend_func_separate.txt

Overview
Blending capability is extended by defining a function that allows
independent setting of the RGB and alpha blend factors for blend
operations that require source and destination blend factors. It
is not always desired that the blending used for RGB is also applied
to alpha.

[aths]

Und sowas einfaches kann meine Karte nicht? Zum heul0rn... :(

[Demirug]

Original geschrieben von aths
Und sowas einfaches kann meine Karte nicht? Zum heul0rn... :(

Das geht bei nv erst ab den FXen bei ATI ab dem R200.

[JTHawK]

Original geschrieben von aths
Weiß jemand, was GL_EXT_blend_func_seperate macht?

Übrigens brauchst du da nur mit der rechten Maustaste drauf klicken und dann auch auf "search blablabla" und der zeigt dir gleich die Spezifikation an.

Bei meiner 8500 siehts so aus:

1.2 - 100% 11/11
1.3 - 88% 8/9
1.4 - 92% 13/14
1.5 - 30% 3/10

sehr lustig ... :D

ATI sagt ja selbst nur: Supports OpenGL® 1.3 features
da könnten se auch 1.4 oder gleich 1.5 hinsetzten .. stimmt doch :D

[zeckensack]

Original geschrieben von aths
Weiß jemand, was GL_EXT_blend_func_seperate macht? Noch ein Grund, die Dienste von Delphi3D (http://www.delphi3d.net/) in Anspruch zu nehmen :)
(von dort kommt GLinfo2)

Hier (http://www.delphi3d.net/hardware/index.php/) findet sich die Extension-Datenbank. Von dort kann man nicht nur sehen, welche Extensions auf welchen Karten unterstützt werden (http://www.delphi3d.net/hardware/allexts.php), sondern recht komfortabel gleich noch nach der zugehörigen Spezifikation fischen gehen :)

Das "Prozentangabe von Version x.y"-Feature ist allerdings sehr interessant :)

[Demirug]

Original geschrieben von zeckensack
Das "Prozentangabe von Version x.y"-Feature ist allerdings sehr interessant :)

Sowas gab es auch mal für DX. Allerdings wurde das Programm leider nicht mehr für DX8 - DX9 nachgezogen.

[Razor]

So wie ich das sehe, ist nVidia näher an der OGL1.5-Spec, als es ATI derzeit ist...
:D

Razor

P.S.: Detonator 44.71 WHQL quadro-certified (FX5900)

[zeckensack]

Original geschrieben von Razor
So wie ich das sehe, ist nVidia näher an der OGL1.5-Spec, als es ATI derzeit ist...
:D

Razor

P.S.: Detonator 44.71 WHQL quadro-certified (FX5900) <überflüssige Stichelei entfernt>

Laut 'Corollaries' ist zumindest R300 vollständig GL1.4-fähig. R200 muß ich noch nachprüfen.

Die Angaben, welche Features neu sind, findet man dabei im entsprechenden Anhang der jeweiligen Kern-Spezifikation (http://www.opengl.org/developers/documentation/specs.html).

Und die 1.5er Spec ist noch garnicht veröffentlicht :|

[BadFred]

Vielleicht interessiert's ja wen:

NV20 mit Det 44.65:

OGl 1.2 100% (11/11)
OGl 1.3 100% (9/9)
OGl 1.4 92% (13/14)
OGl 1.5 50% (5/10)

[Ailuros]

Original geschrieben von zeckensack
<überflüssige Stichelei entfernt>

Laut 'Corollaries' ist zumindest R300 vollständig GL1.4-fähig. R200 muß ich noch nachprüfen.

Die Angaben, welche Features neu sind, findet man dabei im entsprechenden Anhang der jeweiligen Kern-Spezifikation (http://www.opengl.org/developers/documentation/specs.html).

Und die 1.5er Spec ist noch garnicht veröffentlicht :|

Ausser Carmack, wieviele grosse Entwickler beschaeftigen sich noch mit OGL? Eingentlich eine Schande da ich OGL als API (nur aus der User-Perspektive) auch mag.

[Demirug]

Original geschrieben von Ailuros
Ausser Carmack, wieviele grosse Entwickler beschaeftigen sich noch mit OGL? Eingentlich eine Schande da ich OGL als API (nur aus der User-Perspektive) auch mag.

Wenige da es das ARB ja erfolgreich geschaft hat den Entwicklern OpenGL so richtig madig zu machen. Die Vorteile wiegen für die meisten Entwicklern nicht mehr schwer genug um die Nachteile auszugleichen.

[zeckensack]

Original geschrieben von Demirug
Wenige da es das ARB ja erfolgreich geschaft hat den Entwicklern OpenGL so richtig madig zu machen. Die Vorteile wiegen für die meisten Entwicklern nicht mehr schwer genug um die Nachteile auszugleichen. ???

Nachteile? Der einzige echte Nachteil, der sich nicht auf eine bewußte Design-Entscheidung zurückführen lässt, ist daß es im Schnitt länger dauert, bis ein Feature einheitlich angesprochen werden kann.

Ich behaupte, für mindestens 95% aller veröffentlichten Spiele (ala Autobahn Raser, die schier endlose Tomb Raider-Serie und die Sims) ist das de facto irrelevant.
Die benötigten Features für solche Massen-Spiele waren immer rechtzeitg da (tm).

[Quasar]

Original geschrieben von zeckensack
Und die 1.5er Spec ist noch garnicht veröffentlicht :|

Was ist das denn?
http://www.sgi.com/newsroom/press_releases/2003/july/opengl15.html

Nur eine Ankündigung der Spec? Scheiss-Marketing...

[zeckensack]

Original geschrieben von Quasar
Was ist das denn?
http://www.sgi.com/newsroom/press_releases/2003/july/opengl15.html

Nur eine Ankündigung der Spec? Scheiss-Marketing... Verstehen tu' ich's auch nicht. Ich weiß nur, daß die Spec da wo sie sein sollte (http://www.opengl.org/developers/documentation/specs.html) noch nicht existiert.

[Quasar]

Der Vollständigkeit halber:

[JTHawK]

Original geschrieben von Quasar
Der Vollständigkeit halber:

9800 pro ?

[Demirug]

Original geschrieben von zeckensack
???

Nachteile? Der einzige echte Nachteil, der sich nicht auf eine bewußte Design-Entscheidung zurückführen lässt, ist daß es im Schnitt länger dauert, bis ein Feature einheitlich angesprochen werden kann.

Ich behaupte, für mindestens 95% aller veröffentlichten Spiele (ala Autobahn Raser, die schier endlose Tomb Raider-Serie und die Sims) ist das de facto irrelevant.
Die benötigten Features für solche Massen-Spiele waren immer rechtzeitg da (tm).

Es gibt bis heute noch keine Einheitliche Schnittstelle für Per Fragment Effekte mit DX 8 Level Karten und auch bei den Vertexprogrammen hat man sich viel Zeit gelassen.

Zudem braucht man als Entwickler die entsprechende Schnittstellen mindestens 1 Jahr vor dem Release weil man gegen Ende des Projekts nicht anfangen kann plötzlich noch massenhaft neue Dinge einzubauen.

Was OpenGL leider auch fehlt ist eine vollständige Softwareimplentierung die von allen Herstellern als Verbindlich anerkannt wird. Sowas spart unheimlich Zeit wenn man sich nicht sicher ist wer den nun mist gebaut hat.

Die D3D Debug runtime möchte ich nicht mehr missen müssen. Wenn du eine vergleichbare allgemeine Lösung für OpenGL hast immer her damit.

Es fehlt eine umfangreiche Erweiterungsbibliothek für die Aufgaben die immer wieder anfallen. Man kann sich das zwar alles zusammensuchen aber es ist dann irgendwie leider nicht aus einem Guss.

Zusammengefasst fehlt bei OpenGL die Planungssicherheit und sobald es über die Basisfunktionen einer 3D-API hinausgeht wird es dünn. Im Gegenzug bekommt man Platformunabhängkeit und die möglichkeit aus einer Karte das letzte heraus zu holen.

Bei Spielen ist Platformunabhängkeit etwas was sehr weit hinten auf der Liste steht da es auf einer anderen Platform als Windows kaum einen Markt gibt.

Und wenn man sich zu spezifisch auf eine Karte einschiesst bekommt man nur den Zorn der Leute zu spüren die keine solche Karte haben oder man ist wieder an dem Punkt an dem man für jede Karten einzeln programmieren muss = Zeit = Geld.

[Quasar]

Original geschrieben von JTHawK
9800 pro ?

Ups, ganz vergessen. Aber sollte für jeden R300/R350/RV350 eh dasselbe sein.
War eine R9800.

[Ailuros]

OT Frage: hat jemand eine Ahnung warum EPIC D3D fuer die U2 engine benutzt hat?

Uebrigens hab ich das Gefuehl (ohne sicher zu sein) dass CroTeam auch vielleicht auf D3D umsteigen koennte. *shrug*

[Demirug]

Original geschrieben von Ailuros
OT Frage: hat jemand eine Ahnung warum EPIC D3D fuer die U2 engine benutzt hat?

Hier mal zwei Kommentare von Tim Sweeney zu dem Thema OpenGL und Direct3D

In general, OpenGL drivers have major performance and stability problems on Windows. All the hardware makers are supporting Direct3D first and foremost, so we can see the writing on the wall...it says: "Use the API that gives your customers the best stability and performance, not the one with the theoretically cleanest design". am 30.03.2000

This time, I'd go straight for Direct3D, because it's the fastest 3D API for Windows with the best drivers. As to which one I prefer, that's currently OpenGL, because the API is much more straightforward, but DirectX8 looks to catch up to GL's ease of use. 29.06.2003

[mapel110]

Original geschrieben von Ailuros
OT Frage: hat jemand eine Ahnung warum EPIC D3D fuer die U2 engine benutzt hat?

Uebrigens hab ich das Gefuehl (ohne sicher zu sein) dass CroTeam auch vielleicht auf D3D umsteigen koennte. *shrug*

jo, weil serious sam auch für die xbox kommen soll.

wäre schade drum. unter d3d siehts einfach shice aus.
und unter opengl läufts einfach smoother, mag vielleicht auch am "mageren" d3d support liegen, den die engine bislang hat.

[aths]

Demi, sagen wir es so :) In Delphi kann ich problemlos n OpenGL-Fenster aufmachen und "mal fix" was rendern. Wie ginge das mit D3D??

[Demirug]

Original geschrieben von aths
Demi, sagen wir es so :) In Delphi kann ich problemlos n OpenGL-Fenster aufmachen und "mal fix" was rendern. Wie ginge das mit D3D??

Wenn es unbedingt Delphi sein muss: http://www.ieap.uni-kiel.de/surface/ag-berndt/tutorials/dx-tutorial/lektion1.html

oder

http://www.neobrothers.de/tutorials/einstieg.html

[Ailuros]

Original geschrieben von mapel110
jo, weil serious sam auch für die xbox kommen soll.

wäre schade drum. unter d3d siehts einfach shice aus.
und unter opengl läufts einfach smoother, mag vielleicht auch am "mageren" d3d support liegen, den die engine bislang hat.

XBox oder nicht CroTeam´s naechster Versuch wird PS/VS haben ;)

[micki]

Original geschrieben von Demirug
Es gibt bis heute noch keine Einheitliche Schnittstelle für Per Fragment Effekte mit DX 8 Level Karten und auch bei den Vertexprogrammen hat man sich viel Zeit gelassen.
dafür erscheinen viele dinge sofort wenn die hardware es kann und nicht erst beim release von einer neuen dx version oder durch nen komischen hack meines wissens nach z.B. bei hardware-shadowmaps oder occlusion culling oder jetzt den shadow-buffer von NV

Original geschrieben von Demirug
Zudem braucht man als Entwickler die entsprechende Schnittstellen mindestens 1 Jahr vor dem Release weil man gegen Ende des Projekts nicht anfangen kann plötzlich noch massenhaft neue Dinge einzubauen.
das ist ja auch ein nettes problem von dx, bei opengl kann man mal ne neue erschienene funktion einbauen, wenn neue hardware ein nettes feature hat, bei dx heißt es "es ist zu spät um jetzt noch auf eine neue dx version für das api zuzustellen" und plannungssicherheit ist für mich auch, dass ich ein feature noch lange nutzen kann und nicht das microsoft das als "obsolete" definiert, wie manchmal dx (und das fand ich schon des öfteren sehr ärgerlich)

Original geschrieben von Demirug
Was OpenGL leider auch fehlt ist eine vollständige Softwareimplentierung die von allen Herstellern als Verbindlich anerkannt wird. Sowas spart unheimlich Zeit wenn man sich nicht sicher ist wer den nun mist gebaut hat.
Mesa ist die quasi referenz für oGL und zudem noch nett performant, vielleicht sind dort nicht die aller neutsten features drinne, aber die arbeiten dran ;)

Original geschrieben von Demirug
Die D3D Debug runtime möchte ich nicht mehr missen müssen. Wenn du eine vergleichbare allgemeine Lösung für OpenGL hast immer her damit.
Irgendwie brauch ich sowas bei OGL nicht, dort sind die zusammenhänge aus den fehlern für mich meißtens erkennbar (ich weiß auch nicht weshalb) und dann finde ich relativ schnell den bug. Bei D3D gestalltet sich des öfteren sowas dass es in Retail läuft und debug nicht, oder umgekehrt. z.B. bei projezierten texturen und envmapping darf man laut dx8 doc keine division bei der textur enablen, in retail geht das immer, debug nicht... dafür dann extra das mesh hochtesselieren? damit man nen anderen bug findet... das ist aufwendig und ärgerlich.. sowas hab ich mit oGL irgendwie nicht
aber vielleicht würde ich so einen modus (wenn er nicht die kleine dx bugs hat) auch nicht missen wollen, dafür gibt es aber auch einen wrapper der einem für OGL alles anzeigt was zwischen APP und oGL passiert, so kann man sich auch nette dinge über Qauke3 anschauen.. hab den link gerade nicht hier.. aber unter D3D geht das eher nicht.

Original geschrieben von Demirug
Es fehlt eine umfangreiche Erweiterungsbibliothek für die Aufgaben die immer wieder anfallen. Man kann sich das zwar alles zusammensuchen aber es ist dann irgendwie leider nicht aus einem Guss.
es gibt für ziemlich alles libs die auch mit open... benannt sind, z.B. eine physicengine openDE.. openAL und für mathe nimmt man einfach die MesaLib, die ist gut!


Original geschrieben von Demirug
Zusammengefasst fehlt bei OpenGL die Planungssicherheit und sobald es über die Basisfunktionen einer 3D-API hinausgeht wird es dünn. Im Gegenzug bekommt man Platformunabhängkeit und die möglichkeit aus einer Karte das letzte heraus zu holen.
die planungssicherheit bis zur nächsten dx version ist für mich auch nicht sonderlich toll, da muss man manchmal ganze konzepte der engine umschmeissen, weil m$ mal wieder "kreativ" war.. meine erst oGL engine wäre sicher noch mit vertexshadern lauffähig mit _kleinen_ modifikationen.


Original geschrieben von Demirug
Bei Spielen ist Platformunabhängkeit etwas was sehr weit hinten auf der Liste steht da es auf einer anderen Platform als Windows kaum einen Markt gibt.
sowat würde ich vielleicht für den deutschen mark zustimmen, aber wenn du im amiland ein spielverkaufen möchtest, dann fragen die publisher des öfteren mal "wird das spiel auch für den pc geben?" und wenn man denen sagt "ist nur für pc" ist man raus, platformunabhängigkeit ist eigentlich sehr wichtig, dabei ist aber nicht win<->linux wichtig sondern PS2-GC-XB-PC, da hilft aber oGL nicht viel, da gibt es renderware und änliches, aber für die PS2 gibt es ja schon lange oGL und linux.



Original geschrieben von Demirug
Und wenn man sich zu spezifisch auf eine Karte einschiesst bekommt man nur den Zorn der Leute zu spüren die keine solche Karte haben oder man ist wieder an dem Punkt an dem man für jede Karten einzeln programmieren muss = Zeit = Geld.

da John carmack seine engine von NVidia auf "auch ATI" innerhalb einer woche umgestellt hat (und ATI hatte da einen sehr buggy driver) ist das bei einem gut konzipiertem interface noch wesentlich weniger arbeit.

und welches spiel nutz schon nach einem jahr ein neues dx feature? ziemlich keines da kommt oGL locker nach.





das soll hier kein flamewar von mir sein, ich wollte bloss mal eine gegendarstellung schreiben, ich nutze gerne beide APIs und schreibe privat grundsätzlich auf einem wrapper der wohl auch auf nen echtzeit-raytracer gemapped werden könnte...

MfG
micki

[Demirug]

Original geschrieben von micki
dafür erscheinen viele dinge sofort wenn die hardware es kann und nicht erst beim release von einer neuen dx version oder durch nen komischen hack meines wissens nach z.B. bei hardware-shadowmaps oder occlusion culling oder jetzt den shadow-buffer von NV

Richtig aber eben alles Herstellerspezifisch.

das ist ja auch ein nettes problem von dx, bei opengl kann man mal ne neue erschienene funktion einbauen, wenn neue hardware ein nettes feature hat, bei dx heißt es "es ist zu spät um jetzt noch auf eine neue dx version für das api zuzustellen" und plannungssicherheit ist für mich auch, dass ich ein feature noch lange nutzen kann und nicht das microsoft das als "obsolete" definiert, wie manchmal dx (und das fand ich schon des öfteren sehr ärgerlich)

Ja das wird aber von Version zu Version undramatischer. Von 8 nach 9 ist kaum was zu ändern.


Mesa ist die quasi referenz für oGL und zudem noch nett performant, vielleicht sind dort nicht die aller neutsten features drinne, aber die arbeiten dran ;)

Ja aber auf Mesa kann ich eben keinen festnageln.

Irgendwie brauch ich sowas bei OGL nicht, dort sind die zusammenhänge aus den fehlern für mich meißtens erkennbar (ich weiß auch nicht weshalb) und dann finde ich relativ schnell den bug. Bei D3D gestalltet sich des öfteren sowas dass es in Retail läuft und debug nicht, oder umgekehrt. z.B. bei projezierten texturen und envmapping darf man laut dx8 doc keine division bei der textur enablen, in retail geht das immer, debug nicht... dafür dann extra das mesh hochtesselieren? damit man nen anderen bug findet... das ist aufwendig und ärgerlich.. sowas hab ich mit oGL irgendwie nicht
aber vielleicht würde ich so einen modus (wenn er nicht die kleine dx bugs hat) auch nicht missen wollen, dafür gibt es aber auch einen wrapper der einem für OGL alles anzeigt was zwischen APP und oGL passiert, so kann man sich auch nette dinge über Qauke3 anschauen.. hab den link gerade nicht hier.. aber unter D3D geht das eher nicht.

DXSpy


es gibt für ziemlich alles libs die auch mit open... benannt sind, z.B. eine physicengine openDE.. openAL und für mathe nimmt man einfach die MesaLib, die ist gut!

Das meinte ich nicht. Ich bezog mich auf D3DX.

die planungssicherheit bis zur nächsten dx version ist für mich auch nicht sonderlich toll, da muss man manchmal ganze konzepte der engine umschmeissen, weil m$ mal wieder "kreativ" war.. meine erst oGL engine wäre sicher noch mit vertexshadern lauffähig mit _kleinen_ modifikationen.

Das ordne ich eher unter Investionsschutz ein. Plannungssicherheit ist für mich das ich weiss mit welchen API-Funktionen ich zu welchem Zeitpunkt rechnen kann. Bei OpenGL kommt das eben immer häpchenweise und oft mit minimalen Vorwarnzeiten wenn die Hersteller oder das ARB mal wieder Lust dazu hat.

sowat würde ich vielleicht für den deutschen mark zustimmen, aber wenn du im amiland ein spielverkaufen möchtest, dann fragen die publisher des öfteren mal "wird das spiel auch für den pc geben?" und wenn man denen sagt "ist nur für pc" ist man raus, platformunabhängigkeit ist eigentlich sehr wichtig, dabei ist aber nicht win<->linux wichtig sondern PS2-GC-XB-PC, da hilft aber oGL nicht viel, da gibt es renderware und änliches, aber für die PS2 gibt es ja schon lange oGL und linux.

Ich meinte damit alternative PC-Betriebssystem. Konsolen haben sowieso ihere eigene API und Konzepte.

da John carmack seine engine von NVidia auf "auch ATI" innerhalb einer woche umgestellt hat (und ATI hatte da einen sehr buggy driver) ist das bei einem gut konzipiertem interface noch wesentlich weniger arbeit.

Je mehr ich über DOOM III erfahre desto weniger verwundert mich diese alte Aussage.

und welches spiel nutz schon nach einem jahr ein neues dx feature? ziemlich keines da kommt oGL locker nach.

Durchlaufzeiten. Die solltest du doch eigentlich kennen, oder? Nur weil ein Feature in der Engine gibt es ja noch lange kein Spiel dafür. Jemand muss auch noch Kontent erzeugen der dieses Feature erst mal nutzt. Wenn es nun aber aus welchen Gründen auch immer Geschäftspolitik ist Features erst dann einzubauen wenn es eine Einheitliche Schnittstelle gibt dann hat OpenGL das nachsehen.

das soll hier kein flamewar von mir sein, ich wollte bloss mal eine gegendarstellung schreiben, ich nutze gerne beide APIs und schreibe privat grundsätzlich auf einem wrapper der wohl auch auf nen echtzeit-raytracer gemapped werden könnte...

MfG
micki

Ich habe auch nichts gegen OpenGL im Allgemeinen mir ist eben nur das ARB immer viel zu langsam.

API Neutralität steht bei mir ganz unten auf der Liste. Gerade bei den neuen Elementen (Shader) bewegen sich die APIs immer weiter auseinader was ein neutrales Abbilden über einen Wrapper sehr erschwert.

Aber 3d-APIs sind wie Pizzas da hat jeder andere vorlieben und da man über Geschmak nicht streiten sollte höhre ich wohl besser auf bevor es doch noch einen unnötigen Flamewar gibt.

Beide APIs sind gut und beide API haben Vor und Nachteile die in ihrer Grundsätzlichen Vorgehensweise verankert sind. Jeder soll das benutzten was ihm für sein Projekt besser geeignet scheint.

[micki]

Original geschrieben von Demirug
Richtig aber eben alles Herstellerspezifisch.

und das beste wird dann übernommen und nicht das, was M$ diktiert.. du hast ja selbst nen thread mit einer vermutung wie M$ NV einen auswischen will gestartet, soeine machtausspielung sollte bei OGL nicht passieren. Sicherlich jukt das spieleentwickler nicht, aber an sich kann man sowas nicht gutheißen. gäbe es wie bei oGL ein gruppe die für alle zusammen das beste auswählt, wären wir wohl alle zufriedener.. aber leider ist das nichts.
ich finde es nicht schlimm im Wrapper ne funktion anders zu benennen und die parameter in einer anderen reihenfolge zu übergeben... schliesslich ist die hardware recht gleich.

dx ist nur umgekehrt, in oGL prüft man ob ne graka mehr als den "standard" kann in DX prüft man wieviel vom definierten standard die graka fähig ist zu leisten.

Original geschrieben von Demirug
Ja das wird aber von Version zu Version undramatischer. Von 8 nach 9 ist kaum was zu ändern.

und nichtmal so dramatisch ist das update von version zu version von oGL.


Original geschrieben von Demirug
Ja aber auf Mesa kann ich eben keinen festnageln.

doch kannst du, du kannst dir den source ansehen und prüfen ob alles innerhalb der spezifikationen von oGL läuft, und wenn das so ist, dann ist der festzunagelnde festgenagelt. falls ihr beiden "recht habt" weil die spezifikation so pampig ist, dann ist das bei d3d auch nur auslegungssache, und ich glaube mich zu erinnern dass der refras manchmal "geupdated" wurde... vielleicht weil er nicht nach der hardwarespezifikation von jemandem lief :D


außerdem kennst du die P.S. 1.4 Ati extension sicherlich auch ;)
oder die P.S. 2.0+ NV extension


Original geschrieben von Demirug
Das meinte ich nicht. Ich bezog mich auf D3DX.

für oGL gibt es die ganzen libs, du kannst dir sogar welche aussuchen die du magst, du mußt nicht die komische D3DX implementierung antun. Du kannst SDL nehmen und weiteres

wobei ich am beispiel von openDE es schön finde dass man sehen kann, dass die open.. dem DX voraus ist. aber dx10 hat sicherlich ne DirectPhysics

Original geschrieben von Demirug
Das ordne ich eher unter Investionsschutz ein. Plannungssicherheit ist für mich das ich weiss mit welchen API-Funktionen ich zu welchem Zeitpunkt rechnen kann. Bei OpenGL kommt das eben immer häpchenweise und oft mit minimalen Vorwarnzeiten wenn die Hersteller oder das ARB mal wieder Lust dazu hat.

aber die häppchen sind nur ergänzungen und eigentlich nie veräderung, du kannst dich also auf bestehendes verlassen und auf zukünftiges noch einstellen wenn du möchtest.



Original geschrieben von Demirug
Ich meinte damit alternative PC-Betriebssystem. Konsolen haben sowieso ihere eigene API und Konzepte.

da hast du wohl recht, kaum jemand kauft auf anderen OS wirklich spiele, besonders die open-people nicht. aber alleine schon weil die matrizen von D3D verdreht sind, ist es schonmal dumm, weil alle anderen auf dieser welt die oGL nutzen. und M$ hat wohl mit dem ziel es nicht kompatibel zu machen, diese komische design der matrizen gewählt. wenn man von oGL auf was anderes portiert, ist es einfacher. egal was es ist (sogar die XBOX hat viele oGL konzepte z.B. nicht die d3d transponierten matrizen, weil im vertexshader eh nur die "richtigen" gehen)


Original geschrieben von Demirug
Je mehr ich über DOOM III erfahre desto weniger verwundert mich diese alte Aussage.

das war ein kommentar bei Bebben3Gelände, aber ich denke mir das kann er jedesmal sagen, soviel unterscheiden sich die APIs nicht


Original geschrieben von Demirug
Durchlaufzeiten. Die solltest du doch eigentlich kennen, oder? Nur weil ein Feature in der Engine gibt es ja noch lange kein Spiel dafür. Jemand muss auch noch Kontent erzeugen der dieses Feature erst mal nutzt. Wenn es nun aber aus welchen Gründen auch immer Geschäftspolitik ist Features erst dann einzubauen wenn es eine Einheitliche Schnittstelle gibt dann hat OpenGL das nachsehen.

kenn ich, deswegen denk ich mir, dass es nervt alle 18monate auf ein neues dx... umstellen zu müssen, wenn es doch gerade mit der aktuellen engine gut klappt und der kontent stimmt... alleine die effect-umstellung bei hunderten von denen dauert ewig, es muss ja nicht nur der code angepasst werden, auch der ganze kontent. und dafür kann man sich nicht eben ein tool schreiben, man muss ja schliesslich sehen ob es so läuft wie es soll, dafür arbeiten grafiker dann ewig, nur weil es ne neue dx version gibt.
da ergänzend was an oGL zu basteln ist wesentlich einfacher finde ich!



Original geschrieben von Demirug
Ich habe auch nichts gegen OpenGL im Allgemeinen mir ist eben nur das ARB immer viel zu langsam.

mir ist d3d zu unflexibel und wenn man nen wrapper schreibt, vereinigt man die vorteile, per oGL kann man sich immer die neusten dinge anschauen und mit der d3d umstellung ist es auch einfach, aber der aufwand z.B. um ein eigenes effect-system zu coden und sowas steigt natürlich.


Original geschrieben von Demirug
API Neutralität steht bei mir ganz unten auf der Liste. Gerade bei den neuen Elementen (Shader) bewegen sich die APIs immer weiter auseinader was ein neutrales Abbilden über einen Wrapper sehr erschwert.

da könnte ich dir tage von vollheulen :D


Original geschrieben von Demirug
Aber 3d-APIs sind wie Pizzas da hat jeder andere vorlieben und da man über Geschmak nicht streiten sollte höhre ich wohl besser auf bevor es doch noch einen unnötigen Flamewar gibt.

vielleicht eher wie kleidung, wenn man sich an einen stil gewöhnt hat, mag man keinen anderen mehr tragen, egal wie "in" der ist.
aber in der entwicklungs ist man ja tod wenn man einschläft auf seinen wurzeln...

Original geschrieben von Demirug
Beide APIs sind gut und beide API haben Vor und Nachteile die in ihrer Grundsätzlichen Vorgehensweise verankert sind. Jeder soll das benutzten was ihm für sein Projekt besser geeignet scheint.
ich hab kein gutes fazit :-/

MfG
micki

[BlackArchon]

Na, welcher Grafikchip ist das? :freak:

v1.1 50% (1/2)
v1.2 100% (11/11)
v1.3 88% (8/9)
v1.4 73% (11/15)
v1.5 33% (2/6)
v2.0 0% (0/4)

[ScottManDeath]

TNT2 ?

[ow]

Das kann doch nur ein S3 DC sein würde ich denken.

[Corrail]

Original geschrieben von ow
Das kann doch nur ein S3 DC sein würde ich denken.

Bezweifle ich stark. Deltachrome sollte auf jeden Fall mehr unterstützen!

[del_4901]

Original geschrieben von Corrail
Bezweifle ich stark. Deltachrome sollte auf jeden Fall mehr unterstützen!

mhm ich bin aber auch für DC, weil BlackArchon die gerade in seiner Hütte hat.
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=147380 ;)

[zeckensack]

Dieser Extension Viewer ist eh nutzloses Spielzeug für ahnungslose Versionsnummern-Fetischisten. OpenGL funktioniert einfach nicht nach diesem Prinzip.

Zumal die Einteilung durch den Viewer einfach nur falsch sein kann, aber ich glaube sowieso nicht, dass die Herren Autoren wissen, was sie da eigentlich tun.

/rant
sry ;(
Vernünftige Infos (http://www.delphi3d.net/hardware/viewreport.php?report=1028)

[BlackArchon]

Original geschrieben von ow
Das kann doch nur ein S3 DC sein würde ich denken. Richtig, das ist der Deltachrome S8.

[Corrail]

Original geschrieben von zeckensack
Dieser Extension Viewer ist eh nutzloses Spielzeug für ahnungslose Versionsnummern-Fetischisten. OpenGL funktioniert einfach nicht nach diesem Prinzip.

Zumal die Einteilung durch den Viewer einfach nur falsch sein kann, aber ich glaube sowieso nicht, dass die Herren Autoren wissen, was sie da eigentlich tun.

/rant
sry ;(
Vernünftige Infos (http://www.delphi3d.net/hardware/viewreport.php?report=1028)

Hab mich schon des öfteren gewundert, dass da irgendwie was nicht so mit Rechten dingen zu geht (z.B. OpenGL 1.5 und EXT_tex_rect, NV_tex_rect, ARB_tex_npo2)... ;)

Aber das der Deltachrome nur so wenig unterstützt (keine ARB_fp/ARB_vpm, ...) kann IMHO nur am frühen Treiber liegen.

[zeckensack]

Original geschrieben von Corrail
Hab mich schon des öfteren gewundert, dass da irgendwie was nicht so mit Rechten dingen zu geht (z.B. OpenGL 1.5 und EXT_tex_rect, NV_tex_rect, ARB_tex_npo2)... ;)Viel blöder ist doch die Sache mit "GL1.1 - 50%". Klarer Fall von Prinzip nicht verstanden, bitte setzen.

Der Treiber meldet 1.4, also ist er auch 1.4. Fertig, Punkt, aus. In diesem Moment braucht sich dieses höchstnützliche Programm überhaupt keinen Dreck mehr darum zu kümmern, welche der beim Wechsel von 1.0 zu 1.1 integrierten Extensions der Treiber meldet. Der Treiber braucht sie nämlich nicht zu melden, er meldet ja nicht nur zum Spass "Version 1.4".

/rant
sry ;(
Aber das der Deltachrome nur so wenig unterstützt (keine ARB_fp/ARB_vpm, ...) kann IMHO nur am frühen Treiber liegen.Ack. Ich werd' da wohl mal ein wenig rumnerven. Vielleicht machen sie's dann schneller, nur damit ich aufhöre X-D

[Quasar]

Gibt es eine Möglichkeit für ein Programm, herauszufinden, welche Features in "Software" und welche in "Hardware" realisiert werden?
AFAIK ist das unter OpenGL (zumindest früher) problemlos erlaubt.

[ScottManDeath]

Original geschrieben von Quasar
Gibt es eine Möglichkeit für ein Programm, herauszufinden, welche Features in "Software" und welche in "Hardware" realisiert werden?
AFAIK ist das unter OpenGL (zumindest früher) problemlos erlaubt.

Nein. Es is ja mehr oder weniger irrelevant ob es in Hardware läuft oder nicht, Hauptsache es läuft schnell. So haben die GF1/2 Karten keinen Vertexshader, so dass die CPU dies übernehmen muss. Dies geschieht mit recht passabler Performance.

Als Indiz kann man aber nehmen welche Extensions der Treiber supported. nVidia z.B. meldet im Treiber nur diese OpenGL Core Features die sie "schnell"(also meistens in HW) unterstützen im Extension String. So sind seit GL 1.2 3D Texturen ein Core Feature. Selbst eine TNT2 unterstützt diese, allerdings nur in der SW Emulation. Der Treiber meldet aber die GL_EXT_texture_3D Extension nicht

Ich z.b. setze für meine Demos z.B. immer die neueste GL Version vorraus, gucke aber ob der Treiber das Feature was ich nutze im Extension String meldet. Wenn ja, nutze ich das Feature über die Core API. Wenn es nicht im String auftaucht gebe ich eine Warnung aus und nutze es trotztdem.

IMO Ist dieser Extension Viewer Dummfug, da hat man mit einem soliden ExtensionString/Version Info nützlicheres and der Hand, da das dumme Tool anscheinend von dummen Leuten geschrieben wurde. ;)

[q@w]

Original geschrieben von ScottManDeath Als Indiz kann man aber nehmen welche Extensions der Treiber supported. nVidia z.B. meldet im Treiber nur diese OpenGL Core Features die sie "schnell"(also meistens in HW) unterstützen im Extension String. So sind seit GL 1.2 3D Texturen ein Core Feature. Selbst eine TNT2 unterstützt diese, allerdings nur in der SW Emulation. Der Treiber meldet aber die GL_EXT_texture_3D Extension nicht

Danke, darauf wollte ich hinaus - ob es möglich wäre, daß dieser Extension Viewer das irgendwie herausbekommt. Wenn er dabei den Umweg über den von dir beschriebenen Extension String gehen muss, wäre das IMO okay, sollte allerdings dokumentiert sein, so daß "dumme Leute" (wie ich) die Core Features (?) nicht mit denen durcheinanderkriegen, die nur über Softwareemulation (CPU) laufen.

Kann es also sein, daß dieser "Extension Viewer" auf dieser Basis arbeitet?

(War jetzt ein bissel konfus, aber auf der Arbeit kann ich nicht so überlegt schreiben, da sind ein paar Ablenkungen zuviel, eine davon hat mich eingestellt und zahlt mein Gayhalt z.B.)

;Q