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

Aktuelle Zeit: Mo Dez 18, 2017 13:38

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



Ein neues Thema erstellen Auf das Thema antworten  [ 26 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 25, 2005 18:00 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Ja, genau. Einige haben schon mit dem Wechseln von Lischkes Header auf dglopengl.pas Probleme. Außerdem ist das ja eh nur befristet, weil das nächste Delphi .Net 2.0 unterstützen wird und es dann ja eh weniger Probleme mit den Delegates gibt. Daher wäre auch schlecht, wenn man dieses automatische Laden für diese kurzfristige Sache aufgeben würde und zu viel ändern würde. Das ist ja bei .Net 1.1 eh letztlich nur ein Kompromiss.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mo Apr 18, 2005 16:56 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Ich habe den Header nochmal für .Net überarbeitet. Insbesondere das Laden der Extensions ist jetzt erweitert worden.

1. ActivateRenderingContext hat jetzt den optionalen Parameter loadext, mit dem angegeben werden kann, ob alle Funktionen automatisch geladen werden sollen.

2. Für jede Extensions und für die normalen Standard Funktionen gibt es jetzt eine Extra Read_*** Funktion, so daß man die Extensions gezielt laden kann.

3.Zu Beginn wird jeder Zeiger auf einen extra Stub gesetzt, der die Funktion beim ersten Zugriff lädt und danach den Zeiger verändert. Falls man die Funktionen mit ActivateRenderingContext(rc,false) nicht alle beim Start lädt, wird die Funktion dann beim ersten Zugriff geladen. Das ist unter .Net der beste Weg, weil es zu lange dauert alle zu laden, funktioniert aber auch bei win32.

Es geht also wie bisher
InitOpenGL
CreateRenderingContext
ActivateRenderingContext

oder
InitOpenGL
CreateRenderingContext
ActivateRenderingContex(...,false)

Desweiteren sind viele sinnvolle Überladungen bei der .Net Version dabei. Wie schon im C# Header ist es möglich direkt Bitmaps bei glTexImage2D anzugeben und glReadPixels gibt z.B. auch direkt ein Bitmap Objekt zurück.
Zeiger werden üblicherweise als Array umgesetzt. Der Header ist mehr als doppelt so groß wie bisher und daher muß das ganze bei den vielen grundlegenden Änderungen natürlich ausführlich getestet werden. Daher werd ich den als Testversion mal in das .Net Forum stellen.
Anhänge sind ja auch 256kb beschränkt. Daher gibt es unter folgendem Link ein Beispielprojekt für Delphi2005 mit Exe Datei.

http://www.3d-seite.de/OpenGL.zip


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 19, 2005 09:53 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Also das mit den Stubs finde ich ist eine recht witzige Idee. Ich stelle mir da gerade die Frage ob wir nicht gleich komplett darauf umstellen sollten? Wobei die Stubs ja auch ne Hammergröße haben. Das sollte der Compiler aber ganz gut optimieren können. Der dürfte dann ja eigentlich auch nur die Methoden laden die auch tatsächlich benutzt werden.

Was mich aber ein wenig arg stört ist die Überladung der OpenGL Methoden. Bzw. mich stört deren Name. Okay. Die sind zwar nur in .NET verfügbar aber deswegen hätte ich nicht die originalen Methoden umbenannt und gewrapped sondern eher andersrum. Also OpenGL Methode ohne Unterstrich und dafür den .NET Methoden ein anderes Kürzel vorgehangen. Ich finde, dass solche Sachen auch eigentlich da drinne gar nichts zu suchen haben. Die Vermischung von .NET, Win32 und Linux ist schon sehr komplex. Das sollten wir durch so etwas nicht noch komplizierter machen.

Ich muss auch ehrlich gestehen, dass ich in dem Header ein wenig den Überblick verlohren habe. Die Fülle an Konstanten, Methoden, etc. machen das alles andere als übersichtlich. Wie wäre es eigentlich, wenn wir die Konstanten, Funktionstypen und Funktionsvariablen mittels Include einbinden. Sprich. Wir machen 3 Includes die ein Mal die Konstanten, ein Mal die Funktionstypen und ein Mal die Funktionsvariablen einbinden. So könnte man den Quellcode ein wenig ausplitten und würde den Überblick über die Zusatzfunktionen nicht verlieren. Delphi hat damit weder bei der Codevervollständigung noch beim Compilieren probleme. Weiß aber nicht ob FreePascal damit klar kommt.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 19, 2005 11:06 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Ohne die Wrapper ist der Gebrauch unter .Net aber extrem umständlich. Wenn man einfach nur direkt übersetzt, dann wird der typenlose Zeiger ein IntPtr, aber damit kann man unter .Net nur schwer was anfangen. Die originale Funktion ist ja bei der Überladung auch ohne Unterstrich immer dabei. z.B. gibt's das glTexImage mit IntPtr,Array und Bitmap. Ebenso die ganzen gl*Pointer Funktionen. Wer also mit der normalen Funktion arbeitet, für den ändert sich ja nichts, nur es geht ja hier um die Anbindung an eine Plattform und unter .Net ist die gebräuchliche Art für diese Daten eben kein typenloser Zeiger sondern ein Array oder Bitmap. Man darf nicht vergessen, dass das keine extra Funktionalität ist, sondern dass diese Typen unter .Net ganz normale Datentypen sind, wie eben Zeiger unter c.
Es wäre aber vielleicht noch sinnvoll die Funktionen mit dem _ am Anfang in den Implementationteils zu verschieben, weil die gar nicht zum Aufruf von außen gedacht sind.

Ne, Include Dateien haben in Pascal nichts zu suchen, außerdem hat man dann vier Dateien und das macht die Benutzung nicht gerade einfacher. Da die alle in einem Block liegen, kann man sich auch einen {$REGION Konstanten'} {$ENDREGION} Block drumlegen und kann das schön auf und zuklappen. Auch wenn der ganze jetzt ein ziemliches Monster ist, mit mehr Dateien wird es sicherlich noch unübersichtlicher, weil die Deklarationen ja voneinander anhängen. In den Stubs werden ja auch die Konstanten benutzt usw..

Habe nochmal den Quelltext neu formatieren lassen und die _ Variablen verschoben. Daher ist die Datei hinter dem Link neu.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 19, 2005 11:51 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Also mit den Includes würde sich nix ändern. Die würde ja in dem Header includiert und Delphi ersetzt den Includebefehl durch den Text aus dem Datei. Das macht er allerdings intern so, dass man davon nichts mitbekommt außer, dass auf der Festplatte 4 Dateien anstelle von einer wären.

Regions funktionieren aber nur, wenn man Delphi 8+ verwendet.

Zu den Wrappern. Ich finde es doof, dass man bei solchen Methoden immer erst einmal eine andere Methode aufruft. Auch wenn man davon im Endeffket nicht viel mitbekommt. Da .Net ja nun mal nicht mit Pointer kann bleibt nichts anderes übrig als einen kompatiblen Weg zu schaffen. Ich hätte das nur von den Namen her anders gemacht, damit man auch sieht, dass es sich dabei nicht um eine Selbstverständlichkeit von OpenGL Handelt sondern um etwas was der Kompatibilität mit .Net dient. So könnte man jetzt den Trugschluss unterliegen, dass es sich dabei um einen Teil von OpenGL handelt.

PS: Wieso haben includes nichts in Pascal zu suchen?

PPS: Wir sollten auch ein paar Optionen am Anfang des Headers unterbringen. {$X+,H+} und ich weiß nicht was sonst noch wichtig wäre.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 19, 2005 18:15 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Das sind zwar alles keine zeitkritischen Methoden, aber ich werde die trotzdem alle inlinen, damit sie ab Delphi 9 dann direkt eingebunden werden. Wegen der try finally Blöcke werden sie ja trotz ihrer geringen Größe nicht vom jit compiler automatisch eingefügt.
[edit] Habe gerade in der Hilfe gelesen, dass inline keine Wirkung hat, falls die Funktion auf Symbole zugreift, die im Implementation Abschnitt deklariert wurden. Daher müssen die Funktionen mit _ entweder, wieder in den Interface Abschnitt, was unsauer ist, weil die ja faktisch private sind oder man muß auf das inlining verzichten.

Wenn jemand im Wiki diese überladenen Methoden sucht, wird er natürlich nichts finden. Aber andererseits ist es auch seltsam, warum die Methode mit dem IntPtr anders heißen soll, als die Methode mit dem Bitmap als Parameter. Schließlich gibt's dafür ja das Überladen und die Methode mit dem Bitmap wird wohl öfter benutzt. Die Funktionalität ist bei beiden die gleiche und beides sind unter .Net gleichberechtigte Datentypen. So Hilfsfunktionen, da stimme ich zu, haben im Header nichts verloren und mir ist das CreateRenderingContext schon zuviel. Aber Dank der Überladung erscheinen sie nicht als Hilfsfunktionen. Man sollte da nicht versuchen sein eigenes OpenGL zu definieren, aber das ist ja hier auch nicht der Fall, gerade weil sich die Wrapper nahtlos in die bisherigen Funktionen einfügen.

In Pascal gibt's dafür ja eher die Units, aber das fällt ja hier weg, weil man dann drei Units einbinden müßte.

Welche konkreten Vorteile hätten denn vier Dateien? Dann müssen die Leute ja immer mehrere Dateien runterladen und verwenden. So ist es zwar eine ziemlich große Datei, aber einfacher zu handhaben, da an einem Stück. Es gehört ja auch logisch alles zusammen. In einer großen Datei mehrere Änderungen durchzuführen ist ja auch sicherlich nicht aufwändiger als die Änderungen über mehrere Dateien verstreut zu machen.


Zuletzt geändert von LarsMiddendorf am Di Apr 19, 2005 20:37, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Di Apr 19, 2005 20:36 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Also, machen wir es doch so. Das Aufteilen kann auch noch warten. Mir persönlich ist es egal, weil ich eh nicht damit arbeiten muß, aber ich möchte auch nicht, dass es nacher wieder Nörgelei oder Mißverständnisse gibt. Deshalb packe ich jetzt erstmal die Beta Version des Headers ins Forum und wegen dem Aufteilen mache ich eine Umfrage. Wenn die Leute lieber das aufgeteilt haben möchten, sollen sie es haben, wenn nicht, dann eben nicht.

Die Sache mit dem InitOpenGL ist jetzt so, daß es ruhig vergessen werden kann. Zur Not ruft CreateRenderingContext das noch auf. Dann hat dieses Problem auch ein Ende.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 20, 2005 07:47 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Zitat:
Das sind zwar alles keine zeitkritischen Methoden, aber ich werde die trotzdem alle inlinen, damit sie ab Delphi 9 dann direkt eingebunden werden. Wegen der try finally Blöcke werden sie ja trotz ihrer geringen Größe nicht vom jit compiler automatisch eingefügt.

Hä? Trotz Kaffee stehe ich gerade aufm Schlauch.

Was die Methoden angeht ist ja auch irgendwo richtig. .Net ist halt irgendwo doof was das angeht. Aber eigentlich ist das schon richtig. Die sollte da mit hin obwohl die eigentlich da auch gar nicht so ganz hingehören würden.

@Includes: Für die Benutzer des Headers wird sich nichts ändern. Die Includes würden in der dglOpengl eingebunden und sonst nirgendwo anders. Im Endeffekt kan denen das auch egal sein wie viele Dateien sie ziehen. Das ist ja eh alles in einem Zip und da dürfte sich an der Größe nichts ändern. Das einzige was es bringen würde wäre für uns ein wenig mehr Aufteilung. Also wir könnten sagen. Datei 1 ist das. Datei 2 ist das und Datei 3 ist das. Was leider nicht geht ist hineindebuggen. Was aber eigentlich auch nicht notwendig ist. Und was mir gerade einfällt. In den Includes kennt er keine Codevervollständigung. Sprich die Typen aus einem anderen Include würde der nicht kennen. Hmmm. Macht die Sache für uns zwar irgendwo übersichtlicher aber auch wieder komplizierter. Na ja. Dann vergiss den Vorschlag. Neue Extension hinzuzufügen ist halt so nur ne sauarbeit und mit jeder funktionalität kommen 2-3 neue Stellen hinzu die man berücksichtigen muss. Macht das natürlich nicht einfacher.

Aber im Großen und Ganzen können wir den Header so auch freigeben. Ich bin halt nur immer erpicht es für beide Seite so einfach wie mögich zu gestalten. Was leider nicht immer geht.

Was mir gerade auch nich einfällt. Hast du den Header im Header angepasst? Also Versionsnummer, History etc. Bzw. auch in der html Datei. Das sollte es dann eigentlich auch gewesen sein. Gute Arbeit im übrigen. :-)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 20, 2005 09:35 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Zitat:
Hä? Trotz Kaffee stehe ich gerade aufm Schlauch.


Das bezog sich auf:

Zitat:
Zu den Wrappern. Ich finde es doof, dass man bei solchen Methoden immer erst einmal eine andere Methode aufruft.

Wenn das ordentlich eingebunden würde von Delphi, dann wäre der eine Aufruf ja weg.

Zitat:
Aber eigentlich ist das schon richtig. Die sollte da mit hin obwohl die eigentlich da auch gar nicht so ganz hingehören würden.

Jetzt steh ich auf dem Schlauch. Also sollen die _Methoden bzw. eher die Variablen in den Interface Abschnitt damit sie geinlined werden können?

Zitat:
Aber im Großen und Ganzen können wir den Header so auch freigeben.

Ok, der Header ist ja, nicht mißverstehen, noch nicht freigegeben, sondern das im .Net Forum ist nur der dringend benötigte Test. Ich gehe mal davon aus, dass das nicht so glatt geht und noch einige Änderungen notwendig sind und ich hoffe, dass ich nichts von dem Linux Teil kaputt gemacht habe. Je nachdem wie groß das Interesse da ist, wird es wohl ein paar Tage dauern, bis die Fehler draußen sind.
Ich werde dann speziell mal bei opengl.org und beim bdn eine Newsmeldung unterbringen. Schließlich ist das der einzigste Header für Windows,Linux und .Net und das alles in einer Datei.

Zitat:
Ich bin halt nur immer erpicht es für beide Seite so einfach wie mögich zu gestalten. Was leider nicht immer geht.

Man kann ja auch ein statisches Include machen. Bei sich auf dem Rechner hat man dann vier Dateien und vor der Weitergabe wird das dann zusammengesetzt.

Der Header ist soweit angepaßt. Was noch fehlt sind die Compilerdirektiven und die Sache mit dem inline. Das werde ich dann noch in die endgültige Version einfügen.[/quote]


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 20, 2005 10:37 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Zitat:
Jetzt steh ich auf dem Schlauch. Also sollen die _Methoden bzw. eher die Variablen in den Interface Abschnitt damit sie geinlined werden können?

Was meinst du eigentlich mit inline? Kann mir da so nichts direkt drunter vorstellen. Naja. Aus C++ Klassen aber ich weiß nicht ob das ein richtiger zusammenhand ist. Aber zu Begin wolltest du die ja in den Implementationteil packen, weil das mit dem Inline nicht so ganz geht. Ich habe da vollstes vertrauen zu dir. Mich hatte an der ganzen Sache nur das ganze drumherum gestört. Was für .net ja ziemlich notwendig scheint.

Zitat:
Ok, der Header ist ja, nicht mißverstehen, noch nicht freigegeben, sondern das im .Net Forum ist nur der dringend benötigte Test. Ich gehe mal davon aus, dass das nicht so glatt geht und noch einige Änderungen notwendig sind und ich hoffe, dass ich nichts von dem Linux Teil kaputt gemacht habe.

Das meinte ich damit.

Zitat:
Man kann ja auch ein statisches Include machen. Bei sich auf dem Rechner hat man dann vier Dateien und vor der Weitergabe wird das dann zusammengesetzt.

Das will ich ja auch nicht. Das macht das alles nur wieder zu umständlich und man hat verschiedenen Versionen davon. Das muss auch nicht sein. Die Idee mit den Regionen dürften da schon ganz okay sein. Sofern das bei früheren Delphiversionen keine Probleme macht. Anderfalls erst ab einer Version oder eben ganz raus. Dabei ging es mir nur darum, dass man sinnvoll damit arbeiten kann und recht genau weiß wo man was machen muss.

Zitat:
Der Header ist soweit angepaßt. Was noch fehlt sind die Compilerdirektiven und die Sache mit dem inline. Das werde ich dann noch in die endgültige Version einfügen.

Als Compilerdirektiven sollten folgende ausreichen.
Code:
  1. {$A4,H+,O+,X+}
  2. {$WARN UNSAFE_TYPE OFF}
  3. {$WARN UNSAFE_CODE OFF}
  4. {$WARN UNSAFE_CAST OFF}

A ist Align für Recordfields. Dürfte eigentlich egal sein aber kann nicht schaden.
H sind Huge Strings. sonst nimmer er anstelle von Strings ShortStrings.
O ist die Optimierung. Das dürfte sich speziell für die STUBs bemerkbar machen, da er die so nur noch aus den Register ausführen dürfte. (Hoffe ich mal)
X ist erweiterte Syntax.

Die Warnungen sind klar. Dann meckert er nicht mehr bei so etwas.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Mi Apr 20, 2005 10:54 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Der Compiler kann ja ab Delphi2005 auch Methoden inlinen. Dafür muß man inline hinter die Methode schreiben und unglücklicherweise darf sie nichts benutzen, was nur aus dem Implementation Abschnitt kommt, weil der Compiler das sonst nicht hinbekommt.
Die Wrapper nutzen aber alle die _Variablen und damit bekommt man dann z.B. die Fehlermeldung:
Zitat:
[Fehler] dglOpenGL.pas(7938): E2441 Im interface-Abschnitt deklarierte Inline-Funktion darf kein lokales Symbol '_glTexImage2D' verwenden


Die Compiler Befehle habe ich einfügt und die Version aktualisiert.


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 26 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Foren-Übersicht » Sonstiges » Community-Projekte


Wer ist online?

Mitglieder in diesem Forum: Google [Bot] und 2 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.026s | 18 Queries | GZIP : On ]