Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Ich habe vorhin die neuste Version der glBitmap freigegeben. Einige werden darauf sicher schon eine ganze Weile gewartet haben. Aber jetzt ist es endlich so weit und sie unterstützt Linux und FreePascal halbwegs sinnvoll.
Außerdem werden noch zusätzlich folgende Bibliotheken unterstützt.
- SDL um einen Datenaustausch mit SDL_surface zu ermöglichen
- SDL_image zum Laden von JPEG und PNG
- libPNG zum Laden und Speichern von PNGs.
- libJPEG zum Laden und Speichern von JPEGs.
Um die glBitmap sinnvoll einsetzen zu können muss sie in vielen Fällen erst einmal konfiguriert werden. Dazu befinden sich innerhalb des Quellcodes ein paar Defines die einzelne Schnittstellen / Bibliotheken aktivieren bzw. deaktivieren. Achtet bitte darauf ob euch der Kompiler Warnungen innerhalb der glBitmap zeigt oder nicht. Der Text derer sagt meistens schon genügend aus. So hoffe ich zu mindest.
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Klingt mindestens interessant. Hast du die Lib auch für nen 64-Bit-Linux getestet? Mich würde interessieren, ob du da probleme mit SDL bekommst.
Gruß Lord Horazont
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
64 Bit habe ich mal ganz ganz ganz kurz getestet. Die libJPEG hatte dort eine Zugriffsverletzung geworfen und mit der libPNG ging es scheinbar. SDL habe ich gar nicht getestet aber in der TextSuite habe ich Probleme mit SDL_ttf weswegen ich denke, dass das in der glBitmap auch nicht gehen wird. Aber das was ich gemacht hatte kann man eigentlich noch nicht mal als Testen bezeichnen. Aber ich werde 64 Bit in jedem Fall noch mal sehr ausführlich beleuchtet.
Registriert: Di Mai 18, 2004 16:45 Beiträge: 2621 Wohnort: Berlin
Programmiersprache: Go, C/C++
Dann kann ich dich schonmal vorwarnen, in der 64bit version von fpc sind nicht alle Fehler dein verschulden.
FPC hat in der 64Bit version noch einige Bugs, z.B. werden auch mal 32Bit Stacks erstellt und 64Bit Stacks abgerufen.
Das schlimme daran ist, dieses Problem findet man extrem schwer raus und dauert lange, bis man das debuggt hat.
Also wenn du keinen Sinn in einen Fehler findest, stell mal deine Parameterübergabe um und guck obs dann geht.
Wenn du dir dein FPC vom SVN auscheckst, dann gibt es das Problem nicht, da es für die nächste Version schon gefixt ist.
_________________ "Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren" Benjamin Franklin
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Das wirkt nicht beruhigend. Aber gut zu wissen, dann weiß ich schon mal in welche Richtung ich bei seltsamen Phänomenen suchen sollte.
SVN Version: Ich programmiere zwar beruflich aber trotzdem (oder gerade deswegen) verabscheue ich es, mir Programme selber kompilieren zu müssen. Aber zu mindest schön zu hören, dass es dann in neueren Versionen nicht mehr zu solchen Problemen kommt.
Mal ne kurze Frage: Bin inzwischen komplett auf SDL_image umgestiegen, da deine GLBitmap - Unit bisher kein freepascal unterstützte. Inzwischen bin ich aber eigentlich sehr zufrieden mit der SDL - Lösung, denn dadurch kann ich etliche Bildformate laden, weit mehr als deine Unit bisher unterstützt. Gibt es denn irgendeinen Vorteil von deiner Unit bzw. Nachtei von SDL_image, den ich gerade nicht sehe?
Registriert: Do Sep 02, 2004 19:42 Beiträge: 4158
Programmiersprache: FreePascal, C++
Der Hauptvorteil dürfte der kleine oder eher große Batzen an Funktionen sein, die mitgeliefert sind, wie z.B. die Möglichkeit, einen Alphakanal anhand einer Farbe hinzuzufügen oder den Alphakanal zu entfernen oder aus einem anderen (Graustufen) Bild zu laden.
Gruß Lord Horazont
_________________ If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung. current projects: ManiacLab; aioxmpp zombofant network • my photostream „Writing code is like writing poetry“ - source unknown
„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb
Registriert: Do Dez 05, 2002 10:35 Beiträge: 4234 Wohnort: Dortmund
Die Frage ist natürlich vollkommen berechtigt. Die glBitmap ist nicht nur da um Dateien einzulesen. Sondern sie ist da um Texturen zu erstellen/"verwalten".
In der aktuellen Version kann man zum Einlesen von PNGs und JPEGs auch SDL_image benutzen. Aber auch nur JPEG und PNG. Die anderen Formate von SDL_image unterstütze ich nicht (BMP, TGA und DDS behandel ich selbst). Denn für Texturen machen auch nicht alle Dateiformate wirklich Sinn.
Die glBitmap bietet nicht nur das Einlesen einer Datei. Sie bietet Schnittstellen zu Delphi TBitmap, SDL_surface, Windows Resourcen etc. Außerdem unterstützt sie eine ganze Reihe an Texturformaten (DXT, RGB8, RGBA8, BGR8, BGRA8, RGBA4 uvm.). Diese Formate werden auch komplett intern behandelt und der Entwickler muss sich nicht mehr darum kümmern. Besondern bei DXT und anderen Formaten ist die Handhabung dann einheitlich. Außerdem überprüfe ich die Parameter von OpenGL ob die entsprechenden Funktionen unterstützt werden. DXT wird automatisch dekomprimiert. BGR(A) automatisch nach RGB(A) umgewandelt. NPOT Texturen und CubeMaps liefern einen Fehler, da ein Eingriff von mir Qualitätsverluste mit sich bringen würde. Anisotropische Filterung lässt sich einstellen und richtet sich nach dem was die Implementation von OpenGL kann. MipMaps im Filter werden automatisch deaktiviert sollten keine MipMaps erstellt werden.
Es ist recht einfach möglich ein Bild zu manipulieren bevor daraus eine Textur erstellt wird. Also zum Beispiel einen Alphakanal hinzufügen etc. Wobei ich da grundsätzlich nur empfehlen kann es bereits in das Bild zu integrieren. Aber es gibt auch die Möglichkeit mit einer Funktionsschnittstelle selber Texturen procedural zu erstellen etc etc etc.
Du kannst die Texturdaten aus OpenGL auch wieder auslesen. Oder einen Bildschirm graben und das wieder als Datei speichern.
Obendrein ist sie Objektorientiert was die Handhabung vereinfacht. Und nach dem Generieren stehen die Höhe/Breite noch zur Verfügung. Parameter der Textur lassen sich noch verändern. Bei der Freigabe des Objektes wird per Default auch die OpenGL Textur gelöscht.
Kurz um. Sie ist dazu da um die Handhabung mit Texturen zu vereinfachen und dem Entwickler nicht mit den ganzen Kleinigkeiten von OpenGL beschäftigen zu lassen. Trotzdem sollte man noch genügend Möglichkeiten haben um ausreichen Einfluss auf das Resultat nehmen zu können.
Aber wenn es nur darum geht eine Hand voll Bilder einzulesen, die immer im passenden Format sein müssen, dann hast du von der glBitmap vermutlich eher nur wenige bis gar keine Vorteile. Muss jeder selbst wissen ob sie ihm etwas nützt oder nicht.
Danke für die Antworten, besonders die unerwartet ausführliche von Lossy eX Fürs einfache Bilderladen reicht dann wohl auch SDL, sollte ich mal in die Verlegenheit kommen, Bilder nachbearbeiten zu müssen, werd ich auf jeden Fall mal einen Blick auf GLBitmap werfen!
Mitglieder in diesem Forum: 0 Mitglieder und 88 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.