DGL
https://delphigl.com/forum/

glBitmap
https://delphigl.com/forum/viewtopic.php?f=14&t=7457
Seite 7 von 9

Autor:  Bergmann89 [ Fr Nov 29, 2013 15:05 ]
Betreff des Beitrags:  Re: glBitmap

Ah, okay. Ich war in der falschen Zeile, weil ich oben drüber paar Zeilen eingefügt hatte ^^
Hab ich jetzt noch hinzugefügt und gepusht.

Autor:  Bergmann89 [ Do Dez 05, 2013 17:52 ]
Betreff des Beitrags:  Re: glBitmap

Wenn keiner mehr was auszusetzen hat würde ich am WE den aktuellen Stand im unstable-Branch als offizielle v3.0.0 releasen :)

Autor:  Bergmann89 [ Sa Dez 21, 2013 22:08 ]
Betreff des Beitrags:  Re: glBitmap

phlegmatiker hat geschrieben:
Extrem nervig die glBitmap zum laufen zu kriegen übrigens, under fpc/laz. Und besonders hübsch ist der Code auch nicht.

2394080958 Abhängigkeiten.

Vampyre's image lib ist da schmucker und quasi nerv-frei.

Originalbeitrag. Anmerkungen kommen eigentlich hier rein ;) Vlt könnte ein Admin den im Projekt-Thread mal löschen?
Was genau nervt dich? Ich entwickel größtenteils auch mit FPC/Laz und ich muss einfach die glBitmap is Projekt kopieren und schon gehts. Keine Abhängigkeiten, keine Probleme. Es sei denn du willst libPNG oder libJPEG nutzen...

€: grad mal n kurzen Blick auf Vampyre's image lib geworfen. Die scheint großtenteils prozedural und nicht objekt-orientiert aufgebaut zu sein. Das der Code da anders zur objekt-orientierten glBitmap ist, ist klar. Dokumentation ist bei Vampyre's image lib auch besser, geb ich zu, aber die glBitmap ist weitestgehend selbst erklärend (mit den Tutorials auf Lossy Ex' Homepage) deshalb kann man darauf eigentlich auch verzichten...

MfG Bergmann.

Autor:  Jens01 [ Sa Dez 13, 2014 12:52 ]
Betreff des Beitrags:  Re: glBitmap

Zitat:
Mir fehlt eine Umgebung für Delphi, libPNG, libJPEG und SDL. Falls da mal jmd mit nachsehen könnte wäre das super.

Habe glBitmap derzeit nicht in Anwendung, habe es aber einfach mal durchkompilieren lassen.
Und das geht mit XE7. Habe aber nur den "GLB_DELPHI"-Schalter aktiviert. Alle anderen waren abgeschaltet. Wenn ein PNG-Schalter aktiv war, dann gabs Fehler. In einer früheren Version hatte ich "GLB_PNGIMAGE" aktiv (aber keinen Source dafür irgendwo runtergeladen).

Autor:  Bergmann89 [ Sa Dez 13, 2014 19:59 ]
Betreff des Beitrags:  Re: glBitmap

Okay, Danke für das Feedback. Ich hab noch ein Delphi7 hier, da gibts die PNGImage aber noch nicht. Mal gucken, vlt werd ich mir mal ne Testversion vom neusten XE installieren...

Autor:  Jens01 [ So Dez 21, 2014 23:42 ]
Betreff des Beitrags:  Re: glBitmap

Vielleicht macht es Sinn glBitmap auf code.google, github, sourceforge, Delphi-Praxis u.ä. zu plazieren, um es bekannter und populärer zu machen. Obgleich es wohl nie einen globalen Durchbruch haben wird, was halt an der Sache liegt, dass eben nur wenige 3D-Grafik machen, noch weniger OpenGl und Pascal. Die jeweilige Relation muss halt multipliziert werden. 8)

P.S.:
Bei mir findet glBitmap gerade keine Anwendung, weil ich derzeit gar keine Texturen nutze. Bei mir sind die Flächen transparent und farbig.

Autor:  end [ Mo Dez 22, 2014 01:21 ]
Betreff des Beitrags:  Re: glBitmap

Was imo noch ziemlich wichtig wäre:

- keine deprecated Features mehr (glEnable(GL_TEXTURE_2D) soll laut Log z.b. deprecated sein)
- bindless Texture Support
- sonstiger OpenGL 4 Kram?

Autor:  Bergmann89 [ Mo Dez 22, 2014 01:22 ]
Betreff des Beitrags:  Re: glBitmap

@Jens01:
Is ne gute Idee. Können wir das vlt bischen auf die Leute verteilen, die diese Portale sowieso nutzen? Delphi-Praxis, Entwickler-Ecke und Lazarus Forum würde ich übernehmen.
Du kannst ja auch einfach farbige Texturen nutzen, was soll der Geiz? :mrgreen:

@end:
Stimmt, was das glEnable betrifft hab ich auch schon überlegt, aber das ist bei nem älteren Context halt noch zwigend notwendig. Bei dem neuen wird dann nur ein Invalid Operation geworfen. Man könnte nen Check einbauen, das der das bei nem neuen Context nicht aufruft, aber da würd ich lieber erstmal sammeln, was da noch so fehlt und das alles mit einmal fixen.

€: wenn ich das DGL_DEPRECATED Define aus dem DGL Header entferne kompiliert es zumindest immer noch, also wird nicht alzu viel falsch sein

Autor:  end [ Mo Dez 22, 2014 01:46 ]
Betreff des Beitrags:  Re: glBitmap

Ich denke ein IFDEF wäre dort angebracht.

Autor:  TAK2004 [ Mo Dez 22, 2014 02:33 ]
Betreff des Beitrags:  Re: glBitmap

Sobald du versucht verschiedene OpenGL Versionen zu unterstützung bist du in der Hölle angekommen.
Man muss explizit wissen, welche Version der Kontext nutzt und wie die Texturen verwendet werden sollen.
Das Problem an OpenGL 3-4 und davor ist, dass man nicht einfach raus bekommen kann welche Version nun welche ist.
Die Version ab zu fragen wurde erst mit OpenGL 3.0 eingebaut und diese gibt auch nicht die des Kontext zurück, sondern die des Treibers.
Code:
  1.     GLint major, minor;
  2.     glGetIntegerv(GL_MAJOR_VERSION, &major);
  3.     glGetIntegerv(GL_MINOR_VERSION, &minor);

Die Calls sind Illegal auf ein OGL 1-2 Kontext und die Funktionspointer ab zu fragen hilft auch nicht, da die Funktionen unabhängig vom Kontext geladen werden und die Extension holen hilft nicht, weil man dies nur korrekt machen kann, wenn man weiß ob es OpenGL 1-2 oder 3-4 ist, sonnst bekommt man deprecated bzw. API Fehler.

Scaleform produziert z.B. auch API Fehler, wenn ich ein 3-4 Kontext erstelle, weil die ihren Code gegen 1-3 geschrieben aber wohl nie die Specs gelesen haben oder mal ein Debugger laufen hatten.
Glew hat auch solche Probleme aber bekommen die laut Bug Tracker seit 2 Jahren nicht gelöst ... .
Alle Tutorials oder source, den ich gefunden hatte bisher machen es auch nicht korrekt.
Man findet die korrekten Wege dann irgendwo tief in Stackoverflow oder gamdev.net forum, wenn man danach sucht.
Ich gebe copy/paste die Schuld und das die Leute zu selten den Code debuggen und in die Specs gucken.

Da hat man 2. Möglichkeiten.
1. glBitmap initialisiert werden und die parameter sind die OpenGL Context Version und auf welchem Thread der Context erstellt wurde.
2. OpenGL raus werfen.

OpenGL ist größtenteils single threaded und an den Thread gebunden, der den Kontext erstellt hat und da sollte man sicher gehen, dass man sein Code nur dort aus führt. Man möchte aber definitiv nicht die Daten in dem Renderthread von der Platte, Speicher oder Netzwerk laden.
Es wird also langsam kniffelig alles in Interfaces zu verpacken, dass man den Code noch in seine eigene Threading Strategie bekommt.
Ich denke Möglichkeit 2. ist da die richtige Wahl und der Code kann, wenn jemand spaß an den Thema hat und der pflege in eine seperate Unit.

Autor:  Bergmann89 [ Mo Dez 22, 2014 03:38 ]
Betreff des Beitrags:  Re: glBitmap

Ein Kompiler-Schalter geht nicht. Denn wenn man nicht expizit sagt, was man für einen Context haben will, dann bekommt man doch immer den größten der geht, oder? Und das ist dann bei älterer Hardware z.B. 2.0 und bei neuerer 3.0.

Wegen der Version könnte man doch glGetString(GL_VERSION) nutzen und die Rückgabe entsprechend parsen, so macht es der DGL Header ja zur Zeit auch. Das sollte dann die Version des Contexts sein, oder?

Multi-Threading ist mit der jetzigen glBitmap auch möglich. Die ganzen Load-, Save- und Convert-Routinen nutzen kein OpenGL und können entsprechend von einem anderen Thread gecallt werden. Ich muss aber zugeben, dass das nirgends in der Doku steht und auch nicht aus dem Aufbau selbst ersichtlich ist :/

Autor:  end [ Mo Dez 22, 2014 04:06 ]
Betreff des Beitrags:  Re: glBitmap

Ich wäre dafür einfach nur noch GL3 aufwärts zu supporten. Alle anderen können ja die alte glBitmap weiternutzen oder so :x

Autor:  TAK2004 [ Mo Dez 22, 2014 12:42 ]
Betreff des Beitrags:  Re: glBitmap

Bergmann89 hat geschrieben:
Ein Kompiler-Schalter geht nicht. Denn wenn man nicht expizit sagt, was man für einen Context haben will, dann bekommt man doch immer den größten der geht, oder? Und das ist dann bei älterer Hardware z.B. 2.0 und bei neuerer 3.0.

Der Nutzer sollte immer wissen, was für ein Context er erzeugt, sonnst macht er was ordentlich falsch.

Wenn man ein Context mit wglCreateContext ertzeugt, dann bekommt man 1.1 bis 2.1, je nach was der Treiber her gibt.
wglCreateContextAttribsARB gibt dir den Context zurück, den du dir auswählst und wenn du keine an gibst, dann den höchsten(aktuell 4.5).

Bergmann89 hat geschrieben:
Wegen der Version könnte man doch glGetString(GL_VERSION) nutzen und die Rückgabe entsprechend parsen, so macht es der DGL Header ja zur Zeit auch. Das sollte dann die Version des Contexts sein, oder?

Nur bis OpenGL 2.1, denn ab 3.0 ist es illegal, denn dort nutzt man dann folgendes.
Code:
  1.     GLint major, minor;
  2.     glGetIntegerv(GL_MAJOR_VERSION, &major);
  3.     glGetIntegerv(GL_MINOR_VERSION, &minor);

Autor:  Bergmann89 [ Mo Dez 22, 2014 16:31 ]
Betreff des Beitrags:  Re: glBitmap

Bist du dir da sicher? In den Referenz Pages von OpenGL 4 steht GL_VERSION als gültiges Argument für glGetString mit drin...

Autor:  Jens01 [ Mo Dez 22, 2014 16:36 ]
Betreff des Beitrags:  Re: glBitmap

Zitat:
Is ne gute Idee. Können wir das vlt bischen auf die Leute verteilen, die diese Portale sowieso nutzen? Delphi-Praxis, Entwickler-Ecke und Lazarus Forum würde ich übernehmen.
Ich bin eigentlich nur in Delphi-Praxis und delphigl angemeldet. Man weiss ja, dass ich gar kein Informatiker bin, sondern vom Bau komme!
Hat Emba nicht vielleicht auch Interesse da etwas Unterstützung zu geben!?
VirtualStringTree und einige andere offene Projekte hat gerade der Cantu im Namen von Emba unterstützt. Das machen die sicherlich, um die neue Generation von Delphi zu pushen, aber vielleicht gibt es ja Interesse bei denen.
Ähh, Du weißt ja, ich kann kein Englisch. :mrgreen:

Seite 7 von 9 Alle Zeiten sind UTC + 1 Stunde
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/