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

Aktuelle Zeit: Fr Jul 11, 2025 04:35

Foren-Übersicht » Programmierung » OpenGL
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 215 Beiträge ]  Gehe zu Seite Vorherige  1 ... 7, 8, 9, 10, 11, 12, 13 ... 15  Nächste
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Di Jun 09, 2009 13:40 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Bitte IMMER den Link aus dem Wiki angeben. Alle andere Links können wegfallen, sich ändern oder zusätzliche Versionen des Headers können entstehen, die so einfach nicht abgedeckt sind. Deswegen war ich auch so frei und hab den mal bei dir (waran) gelöscht.

Sonst hat waran aber durchaus recht. Der aktuelle Header unterstützt OpenGL 3.0. Leider bin ich noch nicht dazu gekommen 3.1 einzubauen. Bzw OpenGL 3 unter Linux funktioniert auch nicht.

Allerdings war das nicht deine Frage. Denn du wolltest gerne einen Header bei dem alle veralteten Methoden weg sind. Möglichkeit 1 wäre, dass man das alles per Defines im Header ausklammert, was veraltet ist. Hätte aber das Problem, dass der Header dadurch nicht übersichtlicher wird. Weil alle anderen Methoden nach wie vor noch so enthalten sind. Möglichkeit 2 wäre ein seperater Header der immer der neusten Version entspricht. Denn genau genommen können in OpenGL 3.2 auch Methoden von 3.1 als veraltet markiert werden und wegfallen. Wie ja auch bei 3.1 mit den Integer VertexAttribs von 3.0 passiert ist. Würde aber bedeuten, dass man 2 seperate Header pflegen müsste. So richtig gefallen mir beide Möglichkeiten nicht.

Bzw ist es auch so, dass ich mit den 1,5 Seiten in der Spezifikation mal gar nichts anfangen kann. Entsprechend hab ich keinen Plan was bleiben darf und was nicht. Seite 2 Monaten oder so gibt es im OpenGL Registry allerdings einen OpenGL 3 Header. Dort sind wohl nur noch die nicht veralteten Methoden enthalten. Allerdings auch nicht eine Erweiterung die nicht im Kern enthalten sind. Wobei ich auch nicht weiß ob die überhaupt noch Relevanz besitzen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Jun 09, 2009 17:04 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 04, 2008 23:15
Beiträge: 39
Wohnort: Oberösterreich
Programmiersprache: ObjPas, C, DivASM
@Lossy eX
Genau das meinte ich.

Meiner Meinung nach ist die Variante mit dem ausklammern der veralteten Methoden nicht unübersichtlich, wenn man es zum Beispiel so wie in der neuesten glext.h macht.
Bz. als erstes alle gültigen Methoden aus Version 2.0 und unterhalb die deprecated Methoden aus Version 2.0 mit bedingter Kompilierung.

Andererseits wäre es sicherlich nicht falsch einen Schlussstrich zu ziehen, und einen neuen Header mit den gültigen Methoden ab V3.x zu erstellen.

Wie es mit den Extensions aussieht würde mich auch interessieren. Nur bei wenigen ARBs in den neuen Headern sind Teile mit deprecated gekennzeichnet (zb. GL_ARB_imaging).


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Jun 09, 2009 17:38 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Hi,

eine idee wäre - auch wenn das ein ziemlicher aufwand evtl wäre, es wie C++ zu machen... also in gl und glext zu trennen.

Die glext würde dann so wie aktuell die dglOpenGL.pas fortlaufen gepflegt werden. die gl.h/pas würde dann jeweils nur das beinhalten was im kern von der jeweiligen OpenGL version ist.

Sprich sobald eine neue OpenGL Version erscheint wird der bislang aktuelle Header nichtmehr weiter angefasst und stattdessen für die neue version ein neuer (ggf. aufbauend auf dem alten) angeboten.

So hätte man dann z.B.

dglOpenGL100.pas
dglOpenGL150.pas
dglOpenGL200.pas
dglOpenGL210.pas
dglOpenGL300.pas
dglOpenGL310.pas
[...]
dglOpenGLext.pas

So könnte man sich den header für die version aussuchen die man unterstüzen möchte und hat mit der ext-variante alle extensions (die ja versions-unabhängig sind) beisammen.

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Jun 09, 2009 20:50 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7810
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ich wollte auch Ajas Modell vorschlagen, allerdings in einer abgeschwächten Version. OpenGL 3.0 bietet uns ja die Gelegenheit einen definierten Neuanfang zu wagen.

Dementsprechend sollten wir einen dglOpenGL20 anbieten, welcher keine OpenGL3 Methoden beinhaltet aber alle alten Varianten. Dieser Header wäre dann stable und würde nicht mehr angefasst werden außer für Bugfixing.
Dazu dann entweder einen dglOpenGL30 bzw. einfach die dglOpenGL weiterführen mit nur noch OpenGL3 Funktionen. Die Frage wäre da, ob man dort bereits wieder veraltete 3er Funktionen drinnen lässt oder nicht.

Diese Lösung hätte den Charme, dass die Nutzer entscheiden können für welche OpenGL Version sie Programmieren und welchen Header sie entsprechend einsetzen. Wer 3er Funktionen benötigt, benötigt gleichzeitig keine 2er und 1er Funktionen mehr, da diese ja nicht wirklich kompatibel sind.

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Jun 14, 2009 11:00 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Sorry hab ne ganze Weile gebraucht. Denn ich bin mir aktuell noch so überhaupt nicht im klaren was solch eine Umstellung für Aufwand mit sich bringt und ob das alles so funktioniert wie das theoretisch sein soll. Deswegen werde ich mir sowas immer erst 3 mal überdenken bevor ich handel. ;)

humflo: Was mich an der Übersicht stört ist, dass zu mindest ich ganz gerne mal in den Header schau um was nachzuschlagen. Und wenn man da so verschiedene große Blöcke hätte die sich alleine durch define oder nicht define unterscheiden. Das finde ich auf Dauer doch etwas komplex. Zu mal ich beim Headerpflegen immer wieder Dinge verschieben müsste etc.


Aber ich habe auch eine generelle Frage ich zu OpenGL 3.0. Das ist wohl etwas was für das Design recht wichtig sein dürfte. Wie läuft das genau bei der Kontexterstellung ab. Sagen wir ich will einen Kontext mit der Version 3.0 haben aber mein System kann schon 3.1+. Bekomme ich dann einen 3.0 Kontext oder einen 3.1? Denn dann könnte es passieren, dass auf dem einem reinen 3.0 System einige Methoden funktionieren und auf einem 3.5 System diese Methode nicht mehr nur deprecated sind sondern schlicht nicht mehr existieren. Dann wäre eine Aufsplittung in einzelne Versionen nämlich irgendwie nich so richtig sinnvoll.

Und nur so als Randbemerkung. Da dieses Modell eh erst mit 3.0 eingeführt wurde wird das auch maximal bis 3.0 zurück führen. Ein Aufsplitung vor 3.0 ist quatsch. :P


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Jun 14, 2009 15:05 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 04, 2008 23:15
Beiträge: 39
Wohnort: Oberösterreich
Programmiersprache: ObjPas, C, DivASM
Hallo,

Ich habe es mittlerweile so gelöst.
- Einen neuen Header erstellt, der keine deprecated Funktionen aus OpenGL 2.1 oder kleiner enthält.
- Aber Funktionen die zb. von Version 3.0 auf 3.1 deprecated sind, sind enthalten (zb. glVertexAttribI1i).

So kann man sich dann entscheiden, will ich einen 3.0 oder 3.1 Kontext nutzten, und es ist nicht so viel arbeit als wenn man für jede Versionen eine eigenen Header hat.

Eine andere Angelegenheit bei einem neuen Header wäre noch die Delphi 2009 Kompatibilität.
Da in D2009 zb. string und PChar eigentlich WideString und PWideChar sind, gibt es mit dem Header Probleme.
Eine Änderung in AnsiString, PAnsiChar usw sollte genügen und keine Probleme bei anderen IDEs verursachen. :D


Zitat:
Aber ich habe auch eine generelle Frage ich zu OpenGL 3.0. Das ist wohl etwas was für das Design recht wichtig sein dürfte. Wie läuft das genau bei der Kontexterstellung ab. Sagen wir ich will einen Kontext mit der Version 3.0 haben aber mein System kann schon 3.1+. Bekomme ich dann einen 3.0 Kontext oder einen 3.1? Denn dann könnte es passieren, dass auf dem einem reinen 3.0 System einige Methoden funktionieren und auf einem 3.5 System diese Methode nicht mehr nur deprecated sind sondern schlicht nicht mehr existieren. Dann wäre eine Aufsplittung in einzelne Versionen nämlich irgendwie nich so richtig sinnvoll.

Wenn man mit wglCreateContextAttribsARB einen 3.0 Context erstellt bekommt man auch einen solchen, auch wenn das System eine höhere Version unterstützen würde.
Sprich man kann explizit angeben welche Version man haben möchte.

humflo


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Jun 14, 2009 16:43 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2623
Wohnort: Berlin
Programmiersprache: Go, C/C++
Beim erstellen gibst du Majorund Minor Nummer an, um die exakten OpenGL Context Version an zufordern.
Des weiteren ist auch wichtig, welches Profiel man anfordert denn wenn das Profiel nicht verfügbar ist, dann bekommt man auch kein Context.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Jun 15, 2009 19:06 
Offline
DGL Member
Benutzeravatar

Registriert: Di Jul 01, 2003 18:59
Beiträge: 887
Wohnort: (The Netherlands)
Programmiersprache: fpc/delphi/java/c#
As it seems the current version of dglopengl does not seem to work with delphi2009. Besides some warnings the function wglGetProcAddress making all opengl extensions fail to work :-(

This is my current dglGetProcAddress (so it works again :-) ):
Code:
  1.  
  2. function dglGetProcAddress(ProcName: String): Pointer;
  3. begin
  4.   Result := GetProcAddress(LibHandle, pchar(ProcName) );
  5.  
  6.   if result <> nil then
  7.     exit;
  8.  
  9.   {$IFDEF Win32}
  10.     if Addr(wglGetProcAddress) <> nil then
  11.       Result := wglGetProcAddress( PChar(PAnsiChar(AnsiString(ProcName)))  );
  12.   {$ELSE}
  13.     if Addr(glXGetProcAddress) <> nil then
  14.       Result := glXGetProcAddress( pchar(ProcName) );
  15.  
  16.     if result <> nil then
  17.       exit;
  18.  
  19.     if Addr(glXGetProcAddressARB) <> nil then
  20.       Result := glXGetProcAddressARB( pchar(ProcName) );
  21.   {$ENDIF}
  22. end;
  23.  


I left the glx to use a simple pchar as i believe that is linux / fpc only.

_________________
http://3das.noeska.com - create adventure games without programming


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jul 16, 2009 15:00 
Offline
DGL Member

Registriert: Mo Mai 03, 2004 01:55
Beiträge: 28
Es gibt nen üblen bug, der mich ziemliche Nerven gekostet hat (siehe http://bugs.freepascal.org/view.php?id=7570), weswegen ich auf einmal Probleme mit Ati2n Normalsmaps hatte ab catalyst 9.4. Im normalen gl Header von fpc wird der umgangen mit

Code:
  1. implementation
  2. {$if defined(cpui386) or defined(cpux86_64)}
  3. uses
  4.   math;
  5. {$endif}

und
Code:
  1.  
  2. initialization
  3. {$if defined(cpui386) or defined(cpux86_64)}
  4.    SetExceptionMask([exInvalidOp, exDenormalized, exZeroDivide,exOverflow, exUnderflow, exPrecision]);
  5.   {$endif}


Somit ist es mit der dglopengl Unit möglich, diverse seltsame Exceptions zu bekommen (zumindest in fpc, von der Beschreibung her könnte das auch in Delphi der Fall sein), obwohl keine Fehler vorhanden sind. Ich denke man sollte dies schnellstmöglichst beheben.

Ich habe auch noch eine weitere Bitte: Editiert doch mal den ersten Beitrag und den Namen des Themas, ich habe erst durch Zufall gesehen, dass es eine neuere Version des Headers gibt...


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Jul 17, 2009 09:38 
Offline
DGL Member

Registriert: Mo Mai 03, 2004 01:55
Beiträge: 28
Erstmal danke für die Änderung des Thementitels ;)

Also ich habe nochmal etwas nachgeforscht, da
Code:
  1. {$IFDEF CPU386}
  2.   Set8087CW($133F);
  3.  {$ENDIF}

ja eigentlich das selbe machen sollte. Es stellt sich heraus, wenn man die Set8087CW Funktion von der fpc math unit nimmt, klappt es. Nutzt man die in der dglopenl definierte, hat es seit catalyst 9.4 keinen Effekt mehr.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Jul 24, 2009 09:49 
Offline
DGL Member

Registriert: Mo Mai 03, 2004 01:55
Beiträge: 28
Ich habe nochmal einen simplen Test gemacht und das standard sdl template (http://wiki.delphigl.com/index.php/Archiv:template_delphi_sdl) so umgeschrieben, dass es eine ATI2N Texture läd. Ihr braucht dafür die vampire imaging library (http://imaginglib.sourceforge.net/). Und eine ATI2N texture (genannt test.dds), kann man einfach mit Gimp erstellen (anhängen ging nicht, da falsche Endung). EDIT: Ist völlig egal, ihr könnt auch .jpg nehmen, da ich gesagt hatte, dass das gewünschte Format ATI2N sein soll... /EDIT. Ihr solltet die dglopengl.pas noch austauschen und auch {$mode delphi} in die sdl.pas schreiben bzw. die neuere nehmen, die bei freepascal dabei ist.

Den Code des Beispiels hab ich wie folgt geändert:

Compileroption
Code:
  1. {$mode delphi}

Neue Units
Code:
  1. imaging,imagingopengl,imagingtypes;


Neue Variable:
Code:
  1.   GlImageHandle: GLuint;


Textur in die Szene eingebaut:
Code:
  1. procedure glDrawScene;
  2. begin
  3.   // Screen- und Tiefenbuffer bereinigen
  4.   glClear( GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT );
  5.  
  6.   glLoadIdentity;
  7.   glTranslatef( -1.5, 0.0, -6.0 );
  8.  
  9.   // Zeichne Dreieck
  10.   glcolor3f(1,0,0);
  11.   glBegin( GL_TRIANGLES );
  12.     glVertex3f( 0.0, 1.0, 0.0 );
  13.     glVertex3f( 1.0, -1.0, 0.0 );
  14.     glVertex3f( -1.0, -1.0, 0.0 );
  15.   glEnd;
  16.  
  17.   glTranslatef( 3.0, 0.0, 0.0 );
  18.   glEnable(GL_TEXTURE_2D);
  19.   glBindTexture(GL_TEXTURE_2D,GlImageHandle);
  20.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR);
  21.   glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);
  22.   glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
  23.   // Zeichne ein Quadrat
  24.   glcolor3f(0,1,0);  
  25.   glBegin( GL_QUADS );
  26.     glTexCoord2d(1.0,0.0);
  27.     glVertex3f( -1.0, 1.0, 0.0 );
  28.     glTexCoord2d(0.0,0.0);
  29.     glVertex3f( 1.0, 1.0, 0.0 );
  30.     glTexCoord2d(0.0,1.0);
  31.     glVertex3f( 1.0, -1.0, 0.0 );
  32.     glTexCoord2d(1.0,1.0);
  33.     glVertex3f( -1.0, -1.0, 0.0 );
  34.   glEnd;
  35.   glDisable(GL_TEXTURE_2D);
  36.   // Buffer-Wechseln ==> Anzeigen
  37.   SDL_GL_SwapBuffers;
  38. end;


ATI2N Textur laden (ggf. Endung ändern, Zielformat ist immer ATI2N):
Code:
  1. function loadDdsImage:GLuint;
  2. var Img:TimageData;
  3. w,h:longint;
  4. begin
  5.  LoadImageFromFile('test.dds',Img);
  6.  result:=CreateGLTextureFromImage(Img,0,0,false,ifATI2n,@h,@w);
  7. end;


Vor der Hauptschleife im Programm
Code:
  1. GlImageHandle:=loadDdsImage;


Getestet hab ich jetzt mit dem Programm nur auf Vista auf ner 4570 mobility und catalyst 9.5, das Problem hatte ich aber mit ner 4850 unter XP64 auch schon mit catalyst 9.4 und 9.5.

Edit: Zielformat ifDXT3 und ifDXT5 crasht auch, ifDXT1 geht, ifATI1N geht auch.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Jul 24, 2009 13:04 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Erst mal danke, dass du dir so viel Mühe gemacht um das mit Set8087CW rauszufinden. Ich habe schon immer gefragt was das für einen Sinn haben soll, da die Methode aus der dglOpenGL lediglich eine Konstante überschreibt. Gerade hatte ich aber gesehen, dass in Delphi noch befehle der fpu aufgerufen werden. Ich werde das entsprechend anpassen.

Allderdings zu deinem letzten Post. Nicht falsch verstehen aber was zum Geier willst du damit sagen? Sorry aber ich verstehe es absolut nicht.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Jul 24, 2009 15:43 
Offline
DGL Member

Registriert: Mo Mai 03, 2004 01:55
Beiträge: 28
Keine Ursache, ich dachte wenn ich schon so lange gesucht habe sollen andere sich nicht auch noch drüber ärgern müssen...

Bez des letzten Beitrag: Das sollte es nur einfach machen, damit ihr das nachvollziehen könnt, außerdem hatte ich mich sowieso gefragt, ob er auch beim simplen Texturbinden crasht (evtl kommen ja noch mehr Faktoren hinzu). Jetzt hab ich einfach für Faule etwas Code gepostet, da kann jeder selbst den Fehler reproduzieren, sofern er die entsprechende Hardware hat.


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: Di Dez 22, 2009 19:42 
Offline
DGL Member
Benutzeravatar

Registriert: Di Jul 01, 2003 18:59
Beiträge: 887
Wohnort: (The Netherlands)
Programmiersprache: fpc/delphi/java/c#
OpenGL 3.2 - Headertranslation
Version 3.2.2
Date : 16.12.2009

row 6577 should be:
TglGetAttribLocation = function(programObj: GLhandle; char: PGLChar): glint; {$IFDEF DGL_WIN}stdcall; {$ELSE}cdecl; {$ENDIF}

_________________
http://3das.noeska.com - create adventure games without programming


Nach oben
 Profil  
Mit Zitat antworten  
BeitragVerfasst: So Dez 27, 2009 21:03 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7810
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Ich hab die Versionsgeschichte mal aktualisiert. Die letzten 4 Änderungen waren nicht aufgeführt und es sah aus, als wäre der Header noch von 2007.

_________________
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  [ 215 Beiträge ]  Gehe zu Seite Vorherige  1 ... 7, 8, 9, 10, 11, 12, 13 ... 15  Nächste
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: Bing [Bot] und 12 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:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.010s | 15 Queries | GZIP : On ]