Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Mär 29, 2024 14:09

Foren-Übersicht » Sonstiges » Community-Projekte
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 10 Beiträge ] 
Autor Nachricht
 Betreff des Beitrags: [WIKI] Kernfunktionalitäten
BeitragVerfasst: Mi Nov 30, 2005 16:24 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Mir ist gerade durch eine Bearbeitung aufgefallen, dass die Extensions zwar wunderbar aufgelistet werden aber man so keinen direkten Zusammenhang zwischen den Einzellnen OpenGL Versionen finden kann.
GL_ARB_occlusion_query zum Beispiel ist in den 1.5er Kern gewandert.
GL_ARB_texture_cube_map und GL_ARB_texture_env_combine sind Bestandteil von OpenGL 1.3.

Wäre schön, wenn man das in Zukunft irgendwie sehen könnte. Bin auch bereit mein Wissen über die (macht) Extension mit einfließen zu lassen und bei Gelegenheit auch welche zu übertragen. Habe aber jetzt keine Ahnung wie man das sinnvollste gestallten könnte. Auf der Extensionseite halt noch einen Überpunkt mit den einzelnen Versionen als Unterpunkte. Alsp der Überpunkt auf dem Level vom ARB und EXT. Nur auf den einzellnen Extensionsseiten müsste man das ja auch kennzeichnen. Und da weiß ich nicht wie man das am besten machen sollte, da die Extensions ja auch verändert in den Kern übernommen werden. Passiert zwar nicht oft aber es passiert.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 30, 2005 19:23 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 17, 2005 13:19
Beiträge: 98
Wohnort: Jahnsdorf
Eine relativ einfache Lösung, die mir jetzt auf Anhieb einfallen würde ist die Nutzung von Kategorien für die Versionierung... D.h. alle 1.1er Exts in Extension_1.1, alle 1.2er in Extension_1.2 usw. Damit wäre es sogar möglich, Extensions die in einer OGL-Version noch ARB sind, in der jeweiligen auch als solche einsortieren zu lassen.

Code:
  1. [[Kategorie:Extension_1.2|ARB_do_something]] [[Kategorie:Extension_1.3|EXT_do_something]]


Damit würde zwar in beiden Listen der Name der Extension (genauer des Artikels) auftreten, aber jewils so einsortiert, wie in der Kategorisierung angegeben.

Was ich jetzt aber nicht genau weiß, ist, wie man den Kategorie-Index, der auf jeder Kategorie-Seite angezeigt wird, automatisch in einen Artikel einbinden kann, wie es bei norrmalen Artikeln ja normalerweise möglich ist. ( {{:Kategorie:Extension_1.2}} würde nämlich nur die Beschreibung der Kategorie kopieren, nicht den Index am Ende).

Ich hoffe, das ist erstmal ein Vorschlag ...

_________________
Administrator of Project Omorphia
Bild


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 30, 2005 19:38 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 10:44
Beiträge: 991
Wohnort: Karlsfeld (nahe München)
Also ich wuerde vorschalgen das wir die Extension ohne GL_ARB oder GL_EXT als Kategorie Artikel speichern.
Dann kann man Funktionen ihnen zu ordnen und man braucht den Artikel nicht umbenennen wenn eine ARB Erweiterung zu einer EXT Erweiterung wird oder eine ARB Erweiterung in den Kernel wandert.

Dieser Erweiterungsartikel wird dann zum Unterartikel von der Kategorie:GL gemacht wenn die Funktionen in den Kernel wandern.

Beispiel:
http://wiki.delphigl.com/index.php/Kate ... ER_OBJECTS

MfG
Flo

_________________
Danke an alle, die mir (und anderen) geholfen haben.
So weit... ...so gut


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 30, 2005 19:45 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2067
Programmiersprache: C++
BenBE hat geschrieben:
Code:
  1. [[Kategorie:Extension_1.2|ARB_do_something]] [[Kategorie:Extension_1.3|EXT_do_something]]

Hier habe ich sowas ähnliches Vorgeschlagen.

BenBE hat geschrieben:
Was ich jetzt aber nicht genau weiß, ist, wie man den Kategorie-Index, der auf jeder Kategorie-Seite angezeigt wird, automatisch in einen Artikel einbinden kann, wie es bei norrmalen Artikeln ja normalerweise möglich ist. ( {{:Kategorie:Extension_1.2}} würde nämlich nur die Beschreibung der Kategorie kopieren, nicht den Index am Ende).

Du meinst, dass unten nicht nur die Kategorien stehen, sondern auch mit welchen Namen sie eingetragen wurden?
Leider keine Ahnung wie es geht :(


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 30, 2005 20:02 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 17, 2005 13:19
Beiträge: 98
Wohnort: Jahnsdorf
Nein, mit letzterem meine ich folgendes:

Wenn man mit {{Kategorie:GL}} den Artikel Kategorie:GL per "Vorlage" einbindet, wird nur dessen eigentlicher Text übernommen. Die in diesem Artikel vom Wiki angehängte Liste der Artikel dieser Kategorie wird bei dieser Methode nicht kopiert (was aber in dieser Situation sicherlich hilfreich wäre).

_________________
Administrator of Project Omorphia
Bild


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Nov 30, 2005 23:00 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Für die Übersicht würde sich eine Tabelle anbieten.

Als Spalten wären da Name | 1.0 | 1.1 | 1.2 | ... | 2.0

Und in den Zeilen würde immer eingetragen in welcher Form die Extension vorlag. Hersteller -> ARB -> Ext -> Core (Reihenfolge bin ich mir gerade unsicher... :oops: )

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Dez 01, 2005 03:08 
Offline
DGL Member

Registriert: So Sep 26, 2004 05:57
Beiträge: 190
Wohnort: Linz
Also zum einen würd ich mal meinen, dass keine EXT-Extension in irgend einer Core-Version vorhanden ist, diese Ehre gebührt nur ARB-Extensions :-). Die ARB-Extensions sind häufig kaum mehr als eine modifizierte EXT-Extension oder aber mehrere EXT-Extensions zu einer zusammen gefasst. Ich weiß nicht ob dies wirklich jemals gemacht wurde (mehrere EXT in eine ARB) aber ich könnts mir durchaus vorstellen. Wenn man möchte könnte man aber auch diverse OGL 2.0 Funktionalitäten als Zusammenfassung von einigen EXT-Extensions sehen, also beispielsweise den Pack- und Unpack-Prozessor/-Programm welcher Extensions wie EXT_cmyka oder EXT_422_pixels unnötig macht.

Bei den Extension-Spezifikationen wird hin und wieder ein "Based on: EXT-soundso" verwendet, wobei ein ähnliches Vorgehen auch im Wiki möglich wäre. Beispielsweise unter Abhängigkeiten würde das gut rein passen (wo ich ohnehin der Meinung bin, dass diesem Punkt etwas mehr Aufmerksamkeit gebührt). Aber generell drängt sich mir hier eine Frage auf: wer wird irgendwelche Artikel zu EXT-Extensions schreiben (oder auch nur verwenden) wenn es bereits lange eine ARB-Version davon gibt? Ich würde mal meinen, dass das noch ein paar Jährchen dauert bis jemanden so langweilig ist :-). Gleiches für EXT -> Herstellerspezifisch.

Also eine Unterteilung der ARB-Extensions nach Versionen auf der Hauptseite ... nur zu. Im (ARB-) Extension-Artikel selbst evntl. unter Abhängigkeiten rein, ist aber kein muss.

Aber von der Gleichsetzung von EXT-do_something und ARB-do_something würde ich generell eher abraten, da es meines Wissens nach verhältnismäßig selten vor kommt, dass eine EXT-Extension exakt gleich zu der jeweiligen ARB-Extension ist, und seien es nur ein paar zusätzliche Error-Codes oder dergleichen.

Und weil wir grad von Versionen sprechen: es gibt auch eine 1.2.1 Version wo zwar nur Multitexturing, aber somit auch Funktionen wie glActiveTexture rein fallen ... nur so nebenbei - auf Klugscheisser-Basis - angemerkt :-).


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Dez 01, 2005 10:53 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Ups. Wusste nicht, dass es dazu schon ein aktuelles Thema gab. :roll:

Zitat:
Also zum einen würd ich mal meinen, dass keine EXT-Extension in irgend einer Core-Version vorhanden ist, diese Ehre gebührt nur ARB-Extensions :-).

Muss dir da leider wiedersprechen. 1.3 ist die einzige Version in der ausschließlich nur ARBs eingeflossen sind. 1.1 und 1.2 bestehen nur aus EXT und 2 SGIS Extension.

Zitat:
Die ARB-Extensions sind häufig kaum mehr als eine modifizierte EXT-Extension oder aber mehrere EXT-Extensions zu einer zusammen gefasst.

Das ARB Konsortium adaptiert alle Extension bei denen es ausgeht die könnten für die Zukunft wichtig sein. Wie man bei glSlang sieht haben die auch keine Probleme sich da komplet neue Extensions auszudenken. Also woher die herkommen würde ich nirgendwo dran fest machen wollen.

Zitat:
Aber generell drängt sich mir hier eine Frage auf: wer wird irgendwelche Artikel zu EXT-Extensions schreiben (oder auch nur verwenden) wenn es bereits lange eine ARB-Version davon gibt? Ich würde mal meinen, dass das noch ein paar Jährchen dauert bis jemanden so langweilig ist :-). Gleiches für EXT -> Herstellerspezifisch.

Bei den ARBs haben sich die Herrsteller auf eine Spezifikation geeinigt. Sie sind aber nicht daran gebunden diese Extension auch benutzen zu müssen. ATI zum Bleistift. Von texture_rectangles gibt es eine NV, eine EXT und eine ARB. Alle sind 100%tig gleich. Aber laut Extensions unterstützt ATI nur die EXT Version. ARB_texture_non_power_of_two wird bei ATI lediglich NUR durch den 2.0 Kern unterstützt. Auf einen Extensioneintrag wartet man immer noch vergebens. Ich möchte auch nicht wissen was es da noch alles so für Abgründe gibt.

Leider ist es nun mal so, dass es viele Redundanzen gibt und wenn es lediglich eine zusätzliche Abprüfung einer Extension oder der Kernversion ist, dann finde ich kann man das schon machen. Vor allem da man als Entwickler eine größere Kompatibilität für sein Produkt erreicht und das praktisch ohne großen mehr Aufwand. Aber dazu muss man erst einmal wissen das es solche Querverbidungen zwischen verschiedenen Extension gibt.

Ich will sowieso auch mal ein paar Extension hinzufügen. Vor allem bei denen von denen ich weiß was sie tun. Zwar nicht sofort denn dafür habe ich noch andere Dinge in queue aber vorinformationen sammeln soll helfen. ;-)

Ich würde es wohl eher so sehen, dass man bei der Extension bereits sieht in welchem Kern sie eingeflossen ist und ob es evtl auch redundante Extension gibt. Was ich vor allem als schwierig empfinde ist die Tatsache, dass eine Extension im Kern von der Tatsächlich echten Extension auch abweichen kann. Wobei ich dann sowieso stumpf dafür wäre in diesen speziellen Fällen die Extensions zu verdoppeln. Also eine GL_ARB_shader_objects_core_2_0 oder so.

Frage mich auch gerade ob es nötig ist direkt die Werte für die Konstanten mit abgeben zu müssen? Ich denke mal es würde wesentlich mehr helfen, wenn wir eher beschreiben was damit möglich ist und was man machen müsste. Für die Werte der Konstanten kann man dann immer noch auf die Originalextensions verweisen. Finde ich zu mindest.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Dez 01, 2005 15:11 
Offline
DGL Member

Registriert: So Sep 26, 2004 05:57
Beiträge: 190
Wohnort: Linz
Zitat:
Muss dir da leider wiedersprechen. 1.3 ist die einzige Version in der ausschließlich nur ARBs eingeflossen sind. 1.1 und 1.2 bestehen nur aus EXT und 2 SGIS Extension.

Aye, hab ich mir nur die 1.2.1 und 1.3er Version angeschaut ob das zutrifft ... waren wohl genau die falschen :-). Wobei mir vor allem bei der 1.1er Version ein bisserl zu oft der Satz: "The additions match those of the EXT-soundso extension, except ..." vor kommt, auch bei späteren Versionen scheint das zumindest hin und wieder der Fall zu sein.

Zitat:
Das ARB Konsortium adaptiert alle Extension bei denen es ausgeht die könnten für die Zukunft wichtig sein. Wie man bei glSlang sieht haben die auch keine Probleme sich da komplet neue Extensions auszudenken. Also woher die herkommen würde ich nirgendwo dran fest machen wollen.

Hast recht, hin und wieder besitzen sie die Fähigkeit sich zusammen zu setzen und sich gemeinsam was auszudenken, aber das ist wohl eher selten der Fall :-).

Also bis hierher muss ich wohl gestehen, dass meine etwas vereinfachte Sicht der Dinge die Praxis nicht so ganz tirfft.

Zitat:
Bei den ARBs haben sich die Herrsteller auf eine Spezifikation geeinigt. Sie sind aber nicht daran gebunden diese Extension auch benutzen zu müssen. ATI zum Bleistift. Von texture_rectangles gibt es eine NV, eine EXT und eine ARB. Alle sind 100%tig gleich. Aber laut Extensions unterstützt ATI nur die EXT Version.

Also als Grafikkartenhersteller denke ich mir wahrscheinlich: Wenn bei meiner Grafikkarte irgend ne NV-Extension vor kommt, dann denken sich alle ATI is schlecht(er), deshalb greife ich auf eine EXT-Extension zurück wenn ich die Möglichkeit dazu habe. Hinsichtlich der EXT und der ARB-Version existiert jedoch ein gravierender Unterschied, und zwar ist die ARB-Version auf einen neueren Stand der gesamt-API gebracht worden (was ja auch Aufgabe des ARB ist), wodurch jedoch Shader-Unterstützung für texture-rectangles gefordert wird. Warum die bisher zu blöd waren das auf ihren Grafikkarten umzusetzen ... keine Ahnung. Aber genau solche Feinheiten sind es, die es gefährlich machen EXT-Extensions und ARB- bzw. auch Core-Funktionalität gleichzusetzen. Also das Gleichsetzen würde ich wirklich nur dann machen wenn da steht: "The additions match those of the EXT-soundso extension." aber ohne "wenn und aber".

Zitat:
Leider ist es nun mal so, dass es viele Redundanzen gibt und wenn es lediglich eine zusätzliche Abprüfung einer Extension oder der Kernversion ist, dann finde ich kann man das schon machen. Vor allem da man als Entwickler eine größere Kompatibilität für sein Produkt erreicht und das praktisch ohne großen mehr Aufwand. Aber dazu muss man erst einmal wissen das es solche Querverbidungen zwischen verschiedenen Extension gibt.

Ja in der Entwicklung ist es hin und wieder sinnvoll, wobei man sich hier als Entwickler auch überlegen sollte, ob man solche Eigenbrötler die sich nicht an die standardisierteste Form halten (also statt EXT eine Hersteller-Extension bzw. statt ARB eine EXT-Extension) unterstützen möchte. Als Profesioneller hat man zwar kaum eine Wahl, aber gerade als Hobby-Entwickler - wo man meist ohnehin nicht die Zeit hat jede dumme Extension zu unterstützen die dir wieder ein paar Promille Performance bringt - hat man die Wahl und hier müsste ich schon einen guten Grund haben, dass ich eine Hersteller- oder EXT-Extension verwende wenn es eine ARB gibt. Ein guter Grund wäre aber natürlich auch, wenn es eine Sache von 5min Programmieraufwand ist :-).

Die Frage die sich bei derartigen Extensions (also Extensions wo es 2-3 ähnliche Versionen gibt) stelt ist halt, ob es sinnvoll ist einen eigenen Artikel für jede dieser Versionen zu machen, wo sich ein großteil davon aus Copy-Paste Geschichten zusammen setzen dürfte (siehe zB glLinkProgram und glLinkProgramARB). Aber bei solchen Sachen könnte man ja ggf. einfach unter Abhängigkeiten (oder auch einen Punkt Versionen) was dazu schreiben im Sinne von:
EXT_texture_rectangle ist gleich wie diese Extension, jedoch setzt sie keine Fragment Shader voraus, usw. und so fort.
Und dann keinen eigenen Artikel mehr für EXT_texture_rectangle, höchstens noch einen wo nur drinnen steht: "Siehe ARB_texture_rectangle" bzw. gleich eine Weiterleitung.

Wenn es Unterscheidungen zwischen einer Extension und einer Core-Version gibt, so würde ich da auch ähnlich vor gehen, also die im Core vorzufindende Variante der Extension als eigentlichen Artikel, und nur am Ende den Hinweis:
Dieser Artikel beschreibt das Verhalten von OGL 1.X und basiert auf der Extension EXT_sonundso
EXT_sonundso ist gleich bis auf dieses und jenes.
Wobei man hier eventuell als Überschrift nicht EXT_sonundso verwenden sollte, sondern nur den "sonundso"-Teil davon, um eine Unterscheidung zu haben.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Dez 01, 2005 18:30 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7804
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Lossy eX hat geschrieben:
Frage mich auch gerade ob es nötig ist direkt die Werte für die Konstanten mit abgeben zu müssen? Ich denke mal es würde wesentlich mehr helfen, wenn wir eher beschreiben was damit möglich ist und was man machen müsste. Für die Werte der Konstanten kann man dann immer noch auf die Originalextensions verweisen. Finde ich zu mindest.


Daran soll sich nix ändern. Wir erklären ja mit unseren Extensiondokumenten schon mehr als die Orginale. Die Konstanten und so, gehören aber in eine Extensionbeschreibung mit rein. Und den Satz "...kann man dann immer noch auf die Originalextensions verweisen" will ich im Wiki net hören. Schließlich wollen wir mal DIE Quelle sein... :twisted: 8)

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 10 Beiträge ] 
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 18 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
cron
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.069s | 17 Queries | GZIP : On ]