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

Aktuelle Zeit: Fr Mai 26, 2017 14:03

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



Ein neues Thema erstellen Auf das Thema antworten  [ 218 Beiträge ]  Gehe zu Seite 1, 2, 3, 4, 5 ... 15  Nächste
Autor Nachricht
 Betreff des Beitrags: OpenGL 4.5 Header
BeitragVerfasst: Di Sep 09, 2003 14:26 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5795
Programmiersprache: C++
Die aktuelle Version und das dazugehörige Changelog findet sich immer in diesem git-Repository
Dort findet sich auch eine detaillierte Readme (als Markdown) mit Versionsinformationen.

Letzte Änderung am 2015-09-03 :
Code:
  1. - Added missing constant GL_PRIMITIVE_RESTART_FOR_PATCHES_SUPPORTED (SW)
  2. - Added missing constant GL_TEXTURE_BUFFER_BINDING (SW)
  3. - Added missing extension GL_NV_conservative_raster (SW)
  4. - Added recently announced OpenGL extensions :
  5.   - Added GL_ARB_ES3_2_compatibility (SW)
  6.   - Added GL_ARB_fragment_shader_interlock (SW)
  7.   - Added GL_ARB_gpu_shader_int64 (SW)
  8.   - Added GL_ARB_parallel_shader_compile (SW)
  9.   - Added GL_ARB_post_depth_coverage (SW)
  10.   - Added GL_ARB_sample_locations (SW)
  11.   - Added GL_ARB_shader_atomic_counter_ops (SW)
  12.   - Added GL_ARB_shader_ballot (SW)
  13.   - Added GL_ARB_shader_clock (SW)
  14.   - Added GL_ARB_shader_viewport_layer_array (SW)
  15.   - Added GL_ARB_sparse_texture2 (SW)
  16.   - Added GL_ARB_sparse_texture_clamp (SW)
  17.   - Added GL_KHR_no_error (SW)
  18.   - Added GL_NV_conservative_raster_dilate (SW)
  19.   - Added GL_OVR_multiview (SW)
  20.   - Added GL_OVR_multiview2 (SW)
  21.   - Added GL_INTEL_framebuffer_CMAA (SW) 


(wiki Eintrag)

Unterstützt werden Delphi, Free Pascal und diverse Plattformen (Windows, Linux, Mac OS X, etc.)

Der Header wurde so ausgelegt, das ein Umstieg von z.B. Mike Lischkes OpenGL12.pas einfach fallen sollte, denn er enthält sowohl die dort verwendeten Datentypen (z.b. TGLFloat), also auch selbige ohne vorangestelltes "T".Darüberhinaus beherbergt diese Unit auch die an Mike Lischkes Unit angelehnten Helferfunktionen wie z.B. CreateRenderContext und ActivateRendercontext (ersteres mit leicht veränderter Parameteranzahl).

Und auch euer Feedback wurde erhöhrt, und die Probleme mit der bisherigen Unit sollten allesamt behoben sein, auch fehlende Extensions bzw. Konstanten wurden hinzugefügt.

Viel Spaß also mit der neuen Unit, die ihr jetzt getrost als Ersatz für die Unit von ML nutzen könnt (hab meinen Basecode auch schon komplett umgestellt).Aber vergesst bitte nicht, das wir immernoch auf euer Feedback angewiesen sind, weshalb ihr etwaige Probleme oder fehlende Dinge hier posten solltet.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Zuletzt geändert von Sascha Willems am Do Sep 03, 2015 13:07, insgesamt 24-mal geändert.
Link zur dglOpenGL.pas repariert


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Sep 15, 2003 18:00 
Offline
DGL Member
Benutzeravatar

Registriert: Do Jun 19, 2003 18:50
Beiträge: 92
Also mir gehen 2 Typen ab:

TMatrix4d und TVector4i. Fragt mich bitte nicht, ob der Fehler bei mir liegt. Aber direkt nach der Umstellung hat mich mein Compi damit vollgemault.

Des weiteren fehlt die Funktion LoadOpenGL


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Sep 15, 2003 18:06 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5795
Programmiersprache: C++
Alzheimer hat geschrieben:
Also mir gehen 2 Typen ab:

TMatrix4d und TVector4i. Fragt mich bitte nicht, ob der Fehler bei mir liegt. Aber direkt nach der Umstellung hat mich mein Compi damit vollgemault.


Die heissen in unserer Unit momentan noch anders.Wird aber im nächsten Release gefixt.

Alzheimer hat geschrieben:
Des weiteren fehlt die Funktion LoadOpenGL

Die fehlt nicht.Das heisst in unserer Unit InitOpenGL, und mittels glReadExtensions lädst du nach dem Initialisieren des Renderkontextes die Extensions.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Sep 22, 2003 12:39 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 13, 2002 12:18
Beiträge: 1063
Kompliment an alle Beteiligten! Die neue dglOpenGL ist sehr umfangreich und dabei auch noch übersichtlich. Sämtliche Extensions sind mit Kommentaren im Code abgetrennt - da steckt viel Arbeit drin, wie ich auch aus eigener Erfahrung beurteilen kann.

Das Kompilieren von mit Mcad erstellten Ogl Projekten funktioniert mit Hilfe einer kleinen Hilfsunit einwandfrei, allerdings ist folgende Glu- Funktion nicht implementiert:

Code:
  1.   gluBuild3DMipmaps: function(target: GLenum; components, width, height, depth: GLint; format, atype: GLenum;
  2.     Data: Pointer): GLint; stdcall;


die gibt es in der mit Windows gelieferten glu32.dll zwar auch nicht, alternative glu Versionen (ich glaube ab 1.3, bin mir aber nicht sicher), stellen diese aber sehr wohl zur Verfügung (z.B. MesaGLU), obwohl es bei Verwendung von nicht in glu32.dll implementierten Funktionen (zumindest unter Windows) ohnehin eine gute Idee ist, erst mal festzustellen, ob diese überhaupt funktionieren.

Der Source von dglOpenGL ist schön und übersichtlich formatiert, allerdings schaut es so aus, als ob zwei unterschiedliche Formatierungsarten (mit den Einrückungen) zur Anwendung gekommen wären - das Tüpfelchen auf dem i wäre noch, wenn das vereinheitlicht werden könnte.

Was mich bereits bei Lischkes OpenGL12.pas ein wenig gestört hat, sind die vielen ifdefs um Delphi und Kylix gleichermassen zu unterstützen. Während das Unterfangen zwar höchst löblich ist, funktionieren die ganzen Supportroutinen ja ohnehin nur unter Windows, weswegen man die ganzen OpenGL Einsprungpunkte direkt als stdcall definieren könnte.
Die ganzen stdcalls dann bei einer eventuellen Linuxversion (mit eigenen Supportroutinen!) dann durch cdecl zu ersetzen, wäre dank "Suchen und Ersetzen" dann eine Sache von Sekunden - und der Code würde noch etwas übersichtlicher werden.
Was man sich evtl. dann noch überlegen könnte, wäre eine einheitliche Schnittstelle zu Win32 und Linux Systemen, aber das ist, glaube ich, noch ein wenig Zukunftsmusik.

Ansonsten finde ich wirklich nichts mehr zu meckern (und das Angeführte sind ja auch nur Kleinigkeiten) - ich denke hier wurde Delphi OpenGL Programmierern ein großer Dienst erwiesen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Sep 22, 2003 13:56 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5795
Programmiersprache: C++
Erstmal danke für das positive Feedback, sowas sieht man gerne :wink:, und es freut mich das der neue Header auch bei dir ohne größere Probleme funzt.

@ gluBuild3DMipmaps :
Danke für den Hinweis, die Funktion war mir bisher sogar völlig unbekannt.Wird aber auf jeden Fall beim nächsten Headerupdate implementiert.

@ Formatierung & ifdefs :
Wird zur Kenntniss genommen, und im nächsten Release wird da was getan.Ursprünglich sollte der Header auch für Linux nutzbar sein, weshalb da die ganzen ifdefs drin.Allerdings gings uns zuerst mal um eine frühe Veröffentlichung, da es nicht unwahrscheinlich gewesen wäre wenn es GL1.5 bereits in die Catalyst 3.7-Treibern geschafft hätte (dem war leider nicht so).


P.S. : Evtl. für alle NVida-Anhänger ist folgender Thread interessant, denn anscheinend haben NVidia ihrem "wir-cheaten bis zum Umfallen"-Treiber (ich kanns mir leider ned verkneifen...) bereits (zumindest teilweise) OpenGL1.5-Funktionalität drin.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Okt 09, 2003 18:07 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7690
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Also ich habe ein Problemchen mit dem Header... :?
Beim Compilieren meldet er mir folgende Fehler:

Undefinierter Bezeichner: 'PPointer' (bei TGLUTessCombineProc)
Undefinierter Bezeichner: 'RaiseLastOSError'

Ich benutze Delphi 5

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Okt 09, 2003 20:18 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5795
Programmiersprache: C++
Zu PPointer : Wie der Name vermuten lässt, ist PPointer ein Pointer auf einen Pointer.In Delphi 7 ist dieser Datentyp in der Systems.pas definiert,in älteren Versionen anscheinend nicht.Öffene einfach die dglOpenGL.pas und füge bei den vorhandenen Typendeklaratioenen einfach folgendes ein :
Code:
  1. PPointer : ^Pointer


Zu RaiseLastOSError : Komisch das es hier Probleme gibt,denn D5 sollte diese Funktion kennen.Such mal danach in der Hilfe und guck mal (wenns vorhanden ist) in welcher Unit dieses Funktion abgelegt ist und binde diese mal in die dglOpenGL.pas über uses ein.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Okt 09, 2003 21:53 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 13, 2002 12:18
Beiträge: 1063
Unter Delphi 5 heißt der noch RaiseLastWin32Error - erst ab Delphi 6 gabs dann ja Parallelversionen von Delphi und Kylix und dann hat man halt auch die Funktion "betriebssystemunabhängig" gemacht.
RaiseLastWin32Error funktioniert allerdings auch noch in Delphi 6 und 7, läuft dort aber als "veraltete" Funktion - ich denke aber für dglOpenGL ist es sauberer RaiseLastOSError beizubehalten und evtl. einen Kommentar für ältere Delphiversionen (5 und älter) im Header einzufügen, die Prozedurnamen auszutauschen.
Den PPointer könnte man aber auf jeden Fall hinzufügen, folgende Datentypen könnte man noch an die OpenGL Nomenklatur anpassen, welche die Elementgröße (b, f, d u.s.w.) als letztes angibt:

Code:
  1.   TGLArrayf4  = array [0..3] of TGLFloat;
  2.   TGLArrayf3  = array [0..2] of TGLFloat;
  3.   TGLArrayd3  = array [0..2] of TGLDouble;
  4.   TGLArrayi4  = array [0..3] of TGLint;
  5.   TGLArrayp4  = array [0..3] of Pointer;
  6.  
  7.   TGLMatrixf4 = array[0..3, 0..3] of Single;
  8.   TGLMatrixd4 = array[0..3, 0..3] of Double;
  9.  


Eventuell wäre es auch zu überlegen, für diese Datentypen, sowie für die GLU-Datentypen ebenfalls "T"-lose Versionen anzulegen. Irgendwie hat Lischke mit seinem "T" da mehr Verwirrung gestiftet, als schöneren Code erzeugt :D

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Okt 09, 2003 22:05 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5795
Programmiersprache: C++
@ RaiseLastWin32Error :
Danke für den Hinweis mit RaiseLastWin32Error (wusste doch das da noch sowas war),ich werd das dann mal in den Kommentaren des Headers anmerken.

@ Datentypen :
Wurde auch zur Kenntnis genommen und wird auch im nächsten Headerupdate berücksichtig.

@Mike Lischkes "T" :
Sehe ich genauso.Borland sagt zwar man solle seine eigenen Typen mit einem "T" beginnen,allerdings finde ich sowas bei ner Headerkonvertierung nur suboptimal.glFloat wäre mir auch lieber als TGLFloat und würde dann ja letztendlich auch dem Original entsprechen.Allerdings würde dies eine Migration von MLs Header auf unseren verkomplizieren.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Okt 11, 2003 09:05 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5795
Programmiersprache: C++
Hab grade die alte Version durch die aktualisierte ersetzt.Folgende Neuerungen sind jetzt enthalten :

# PPointer deklariert (Kompatibilitätmit Delphi <7)
# Eigene Prozedur RaiseLastOSError+Kommentat (Kompatibilität mit Delphi <7)
# Die von Mars vorgeschlagenen Datentypen mit GL-Syntax eingefügt

Da das alles keine großen Änderungen waren,hab ich die neue Unit nur mit meinem aktuellen Projekt getestet und dort machte sie keine Probleme.Falls es dennoch irgendwo zu Problemen kommen sollte,dann bitte hier im Thread melden.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Okt 16, 2003 14:47 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7690
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Hieß es nicht, am 15 kommt der offizielle 1.5 Header??. Is der jetzt da oder kommt der noch???

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


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Okt 16, 2003 15:02 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5795
Programmiersprache: C++
Das ist der offizielle Header.Es hiess nur das Phob am 15.Oktober das offizielle SDK rausbringt,dies aber zeitlich wohl nicht schafft.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Okt 17, 2003 13:20 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Jul 12, 2002 07:15
Beiträge: 912
Wohnort: Dietzhölztal / Hessen
Programmiersprache: C/C++, Obj-C
Ich bin auf 1,5 Bugs in dem Header gestossen:

0,5: Zeile 8225 -> 2 Zuweisungen stehen in einer Zeile. Eigentlich kein bug, jedoch "unschön". Stört aber nicht. Hab's nur der Vollständigkeit halber erwähnt. ;)

Der andere iss wirklich ein Bug:
Zeile 8263 -> Auch hier sind mehrere Zuweisungs-Befehle in einer Zeile. Wäre ja nur halb so schlimm, wenn am Anfang der Zeile nicht ein //-Kommentar wäre. Somit werden die nachfolgendne Befehle einfach auskommentiert. Betroffen sind die Funktionen von ARB_Vertex_Shader und ARB_Occlusion_Query (glGetActiveAttribARB, glGetAttribLocationARB, glBindAttribLocationARB, glGetVertexAttribPointervARB, glGenQueriesARB und glDeleteQueriesARB).

Ich schätz' mal, dass es sich um die 1.5 Funktionen handelt und diese noch nicht getestet werden konnten. (Das Auskommentieren könnte ja dann auch absicht sein; keine Ahnung). Wollte es ebenfalls nur mal mitteilen.

_________________
Und was würdest Du tun, wenn Du wüsstest, dass morgen Dein letzter Tag auf dieser Erde ist?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Okt 17, 2003 13:24 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5795
Programmiersprache: C++
:shock: Sicher das du den selben Header hast wie er hier angeboten wird?Hab grad nochmal nachgesehen, und bei mir sind die angesprochenen Zeilen und angeblich auskommentierten Funktionen allesamt da...sicher das du den Header hier aus dem Thread hast und nicht aus der DL-Sektion?

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Okt 17, 2003 13:40 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 13, 2002 12:18
Beiträge: 1063
Eigentlich ist bei der Version aus der DL-Sektion auch alles drinnen - obwohl es dennoch Sinn machen würde, beide Versionen abzugleichen.

Kann es sein, dass du evtl. eine ältere Delphiversion verwendest ? Meines Wissens hatte Delphi (ich glaube bis Version 6 oder so) Probleme mit "Linux" Zeilenumbrüchen (also CR anstelle von CRLF).
Hab da auch schon meine Gaudi gehabt, als ich einen C++ Source nach Delphi konvertierte und dann lauter Fehlermeldungen a'la Zeile zu lang (obwohl in der betreffenden Zeile gar nichts stand) bekam, oder (noch lustiger) das Programm beim Tracen völlig falsche Zeilen anzeigte und die diversen Meldungen den Ort eines Fehlers bestenfalls ungefähr erahnen ließen.

Abhilfe schafft, den ganzen Source in Notepad zu laden und nochmal abzuspeichern - am besten lädst du das Ganze vorher nochmal runter, für den Fall, dass sich in deinem Source inzwischen andere Fehler eingeschlichen haben.
Sollte dies tatsächlich der Fehler gewesen sein, sollte man aber unbedingt drauf achten eine "Alt-Delphikompatible" Version hochzuladen.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 218 Beiträge ]  Gehe zu Seite 1, 2, 3, 4, 5 ... 15  Nächste
Foren-Übersicht » Programmierung » OpenGL


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 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.027s | 22 Queries | GZIP : On ]