Also ich kenne dein Problem. Ich habe geschlagene 2 Monate immer wieder damit rumgebastelt. Und ja. Das was die damit veranstalten ist echt ein bisschen krank. Und unter Windows und Linux sogar sehr unterschiedlich. Allerdings habe ich mich daran gewissermaßen verbissen. Letzten Endes habe ich es aber hinbekommen. Also Lesen und Schreiben und das alles sowohl unter Linux mit fpc als auch unter Windows mit Dephi. Ich habe das für die glBitmap gemacht ist aber ein simpler seperater Header den ich noch veröffentlichen wollte (+ 3 Beispiele). Ich kann im Laufe des Tages ein Paket davon machen und den auf meine Seite laden.

PS: Einen header für die libPNG habe ich auch in der Mache aber da bin ich noch nicht dazu gekommen den unter Linux zu testen.

Hey Lossy!
Das würde mich sehr freuen.
@Lord Horazont: Wenn wir wirklich einen Pascal JPeg Header kriegen, würde ich sagen: maybe SDL rulez, but Pascal rulez better.

Gut, dass ich das ganze flexibel gehalten habe. Sollte irgendwann noch einmal eine Platform-Independent FPC Version von Lossy's glBitmap rauskommen, werde ich die selbstverständlich einer gründlichen Prüfung unterziehen.

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

jpeg header: Ich bin mir nicht sicher ob das überall funktioniert und ob das alles so richtig ist. Die Beispiele funktionieren aber sowohl unter Windows als auch unter linux. Beim Schreiben ist die compression_struct allerdings komischerweise noch 4 Bytes größer. Da muss ich wohl noch mal schauen. Hier gibts den Download (20kb).

fpc glBitmap: In arbeit. Compilieren geht aber mit dem eingebauten opengl header gibst komische exceptions. Bzw es fehlen noch einige Sachen.

Hallo Lossy.
Danke nochmal, habs mir schon geholt und eingebaut und es funktioniert auch schon. Zwar mit Falschfarben, aber das ist meine Schuld, weil ich derzeit automatisch Pixelformat 24bit=BMP=BGR (in glTexImage2D) gleichsetze, muss ich noch ändern. Hab das testmäßig umgestellt und mit RGB funktionierts total lecker. Komisch, dass das vorher anders war.

Jedenfalls schrumpft der Code dadurch ganz erheblich, weil die ganze PasJPeg wegfällt.
Traude

Ich hab mich früher auch mit jpeg, png und co geärgert, zum schluss hatte ich libpng und pasjpeg verwendet.

Mitlerweile nutze ich nur noch dds mit dxt1-5 sowie ati1-2, da es das aktuell sinnvollste Format für OpenGL ist und die ganze konvertierung auf Grafikkartenseite passiert und somit keiner weiteren Zeilen im Header braucht. Der große Nachteil an Formaten wie Jpeg,png und co sind, dass sie erstmal konvertiert werden müssen(kostet zeit), dann in aufgeblähter form in den Grakaspeicher kommen(dauert wieder zeit auf dem Datenbus) und dann auch noch ne menge Speicher auf der Graka verschwenden. DXT1-5 und ATI1-2 sind auf Festplatte kompremiert(allerdings nicht so platzsparend), müssen nicht weiter verarbeitet werden und werden in ihrer doch recht kleinen größe über den bus geschickt, verbrauchen weniger vram und können auch von der gpu schneller verarbeitet werden, da weniger takte für ein zugriff gebraucht werden(dauerhaft eine höhere FPS).
Photoshop und Gimp haben Plugins dafür und ob ich speicher als jpeg oder speicher als dds mit ATI2 oder DXT5 klicke ist das gleiche.
Crytek hat für Crysis alle Texturen in ATI2 gespeichert und konvertiert auf Anforderung(wenn die Hardware es nicht im support hat) auf DXT5(dem ATI2 format wohl recht ähnlich) um.

Was will ich damit sagen ? Ganz einfach, es muss nicht immer ein Mainstream Format sein, andere Formate können das Leben oft leichter machen oder sind sogar in vielen Punkten im Vorteil. Einfach mal weiter als bis zum Tellerrand gucken und sich mal umhören, was andere so für Erfahrungen mit Formate haben.

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

Projekte: https://github.com/tak2004

Auch auf die Gefahr hin, dass die Diskussion in Richtung Texturenformate abrutscht. Was ich aber nicht bezwecke. Nur fakt ist, dass DXT1-5 und ATI1 & 2 komprimierte Formate sind und dadurch praktisch immer ein Verlust einher geht. Bei DXT ist der je nach Anwendungsfall noch wesentlich stärker als bei JPEG. Und PNG ist verlustfrei komprimiert. Klar JPEG und PNG sind in der 3D Programmierung evtl nicht so stark vertreten aber die Formate haben durchaus ihre Bewandniss. Kommt halt immer darauf an was man machen will. Und das hat dann nichts mit Mainstream oder Suppentellern zu tun!

Hallo, Ihr Hübschen,
Bin ein bisschen spät dran, weil ich mich mit einem Fileuploader geärgert habe.

Zunächst der Download Link: http://www.2shared.com/file/3018279/d7cddee8/PasGUITest1.html

(Der Link ist unten im rechten Eck ganz klein in blauer Schrift)

Also bitte: Ihr wolltet halbgaren Code, da ist er jetzt. Das ganze ist nur SourceCode, compilieren müsst ihr es euch selbst.
Zur Erinnerung nochmal: es ist ein Windowsprogramm, compilierbar mit Delphi7 (aber ich meine, dass es mit Delphi5 auch gehen müßte).



Ein Hinweis: es ist erforderlich, in die Datei "GUIConfig.txt" VIER MAL Euer Programmverzeichnis einzutragen. Warum steht in der Main.dpr drin. Und die Main.dpr genauer durchlesen, ich habe Hinweise angebracht. Ansonsten steh ich für Fragen gern zur Verfügung.

Noch ein Hinweis: die Datei "StdCompress.pas" gehört eigentlich garnicht rein und ist mir irrtümlich dazwischengerutscht.


Hallo Thomas. Mein Imageloader ist nicht optimal, aber nicht wegen JPeg. All das Zeug soll leicht austauschbar sein, auch der Imageloader. Der einzige Fixpunkt ist der Treecode (GUI.Pas und GUIDescendants.pas).


Ach ja noch etwas: Ich finde die Lizenz bei mir auf der Festplatte nicht. Sie musste noch im Brainstorming Thread drin sein. Ich gehe auf die Suche.



EDIT: Eine Lizenz habe ich nicht gefunden, aber folgenden Text aus dem Beschreibungsdokument des Brainstorming Thread (zu eurer Info: das Dokument ist auch von mir):



Das wird jetzt lustig. Wer sind die Rechteinhaber?

Ich bin einfach mal so frei und geb ein paar kommentare ab.
Was mir ganz zu anfang ins auge gestochen ist, sind die unschönen vermutlich durchs Antialiasing hervorgerufenen sichtbaren Grenzen zwischen den Dreiecken in der Diagonale (screenshot liegt bei). Kann natürlich sein, dass ich der einzige mit dem Problem bin, weshalb auch immer (mein PC lebt!).

Dann habe ich einen Bug in der Scrollbar, ich weiss natürlich nicht, inwiefern dir der schon bekannt ist, zumindest bei der Treebox gefunden: Wenn man ganz auf den Rand klickt, direkt neben den "Zugknopf" (das ding inner mitte), dann verschwindet der Inhalt der Scrollbar, samt Scrollbuttons (siehe 2. Screenshot). Außerdem geht die Scrollbar immer nach ganz oben zurück, wenn man ein Item auswählt.

Ansonsten gefällt mir die GUI, nur über die Farbgebung kann man streiten, aber das ist ja zum glück recht variabel.

Gruß Lord Horazont

//Edit: was mir gerade noch aufgefallen ist: beim MoveablePanel oder was das ist auf dem du die Testcontrols platzierst, wenn man das verkleinert am unteren rechten rand oder woauchimmer fällt auf, dass die daraufliegenden Controls nicht abgeschnitten werden.

_________________
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

Lord Horazont schrieb:

Das kann ich bei mir nicht entdecken. Wenn es wirklich das Antialiasing ist: gesetzt wird es in der Unit GraphicSupport, Prozedur "grsSetParams". Probier mal, das Antialiasing dort auszukommentieren. ALLERDINGS kann es auch daher kommen, dass ich den Viewport garnicht lösche (Methode "T2DGrUtMan.PaintBegin"), und zwar deswegen, weil nur Items gezeichnet werden, die der Meinung sind, dass sie gezeichnet werden müssen. Wenn ich den Viewport lösche, geht das nicht mehr.


Punkt 1 (Inhalt verschwindet): Das muss ich erst überprüfen, dauert ein bisschen.
Punkt 2 (Scrollbar entwickelt Eigenleben beim Auswählen): Das habe ich definitiv bei mir nicht. Darüber muss ich mir den Kopf zerbrechen, was das sein könnte.


Ja, das ist auch meines Erachtens ein Bug, denn sobald das passiert, werden die aussen befindlichen Controls "unempfindlich". Das steht in meiner Bugliste drin.


Farben: mach einfach mal die Themedatei "standard.csv" mit einem beliebigen Texteditor auf. Die grüne Default-Farbe ist dort im ersten Satz definiert. Wenn diese Datei nicht existiert bzw. umbenannt wird, sollten die Items ein graues Aussehen bekommen; das ganze geht in der Methode "TGUIItem.InitAppearance" vor sich.

Skins: Es entsteht vielleicht der Eindruck, dass ich gar keine Skins habe. das ist aber falsch. JEDES Item hat eine Textur zur Verfügung. Nur TGUIImage macht davon Gebrauch. Die andern müsste ich erst dazu bringen, dass sie ihr eingebautes Bild auch anzeigen. Wie das gemacht wird, ist im TGUIImage.Paint zu sehen. Bildchen kann man auch über die Themedatei hineinfüttern (BMP24Bit,TGA32Bit,JPG24Bit).

Shapes: Auch Shapes kann man per Themedatei verändern (aus der Listbox einen Listkreis zu machen ist zwar möglich, aber nicht empfehelenswert, garnicht auszudenken, was passiert, wenn ihr einen kreisförmige Scrollbar setzt). Welche Shape-Strings die Themedatei schluckt, ist in der Funktion "GetShapeByName" in der Unit "StdShape.pas" zu sehen.

Jetzt habe ich aber auch eine Frage an Dich: es ist keine Beschreibung dabei, nur die Übersicht, die ich oben irgendwo hineingehängt habe. Das einzige, was in der Übersicht nicht drinsteht ist, dass sich das Theme-Objekt in der Unit GUIGrUtman.pas befindet. Kennt man sich aus?

Meinst du jetzt Code- oder Oberflächenmäßig das Zurechtfinden?

Was mir gerade aufgefallen ist: Was ist das denn da für ein sehr interessanter Code mit dem Casten auf TMethod? Sowas habe ich ja noch nie gesehen... Was genau passiert da und noch viel interessanter: Was ist der erste Pointer bei den Parametern von OnControlChange?

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

Ich meine den Code. Die Leute sollen sich im Code zurechtfinden. Sie kriegen ja auch die volle Source und man kann die Möglichkeiten nur ausschöpfen (bzw. neue Möglichkeiten hinzufügen), wenn der Sourcecode klar und übersichtlich ist. Dabei ist kein Kriterium, dass ICH ihn klar finde. Es muss sich auch jemand anders in kurzer Zeit drin auskennen.


Casten auf TMethod:
Idee und Vorgabe sowie ein Codeschnipsel stammen von Tak2004. Die genauere weitere Ausführung ist von mir. Man soll sowohl Prozeduren als auch Methoden einhängen können. Wenn Du den Pointer aus der eventhandling Procedure rausnimmst, kriegst Du die Parameter nicht mehr ordentlich rein, denn es wird auf jeden Fall als erster Parameter ein Pointer auf das Objekt übergeben.

Ich schaue mir den Code später mal genauer an, aber was mir spontan aufgefallen ist (hat jetzt weniger mit der Übersichtlichkeit zu tun, wobei es für selbige spricht, dass mir sowas auffällt, weil ich weiss, wo ich suchen muss):
1. (TTheme.Load) Du wirst probleme mit Linux bekommen wegen der groß/kleinschreibung. Du erlaubst es dem GUI-Anwender nicht, die Dateierweiterung mit anzugeben und noch dazu gehst du von einer großgeschriebenen Erweiterung aus, was wohl eher selten vorkommt.
2. Es fehlt eine Möglichkeit, alles über Streams zu laden. Die GUI mag zwar nicht auf Spiele ausgerichtet sein aber auch Anwendungen wollen ihre Theme-Daten, speziell von Skins, in Archiven speichern anstatt in einzelnen Dateien, was die benutzung von Streams erforderlich macht, wenn man nicht gerade beim Auswählen/Laden eines Skins alle Dateien entpacken will.
Wenn hierbei der Hinderungsgrund ist, dass du ein Textformat für die Daten verwenden willst, kannst du mich mal anschreiben, ich habe hier eine gut funktionierende Prozedur (nichtwahr, MatReno? ), die das ReadLn für Streams ermöglicht.

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

Ja, ich weiß. Alle Ladevorgänge muss ich noch auf Linux-Tauglichkeit überprüfen (auch bei Bildern) aber ich kann nicht, ich hab mir immer noch kein Linux aufgesetzt.

Das mit den Streams: die Daten sind bewußt so einfach gehalten, dass jeder seine eigene Theme-Daten so laden kann wie er will. Manche mögen nicht, wenn man die Daten per Hand ändern kann, da können auch Fehler passieren. Wenn Ihr Euch über ein Format einig seid, könnte ich das implementieren bzw. vielleicht sogar DU? Vorsicht, gib mir nicht den kleinen Finger, sonst habe ich gleich die ganze Hand.
Traude

Hmm... Also grundsätzlich bin ich immer bereit zu helfen. Die Frage ist nur, ob sich das jetzt schon lohnt, wenn noch einige Änderungen anstehen. Am einfachsten wäre es, wenn alle GUI-Komponenten von TPersistent abgeleitet sind (sind sie?) oder die Urkomponente einfach in einen {$M+} ... {$M-}-Block klemmt (für RTTI), da man dann einfach alle Published-Dinger nimmt und sie in einen Stream schreibt bzw sie beim Laden wieder liest. Mit dieser Methode wäre man auch auf spätere Änderungen an den Komponenten bzw deren Eigenschaften vorbereitet. Eine weitere Vorraussetzung ist dann halt, dass alle Endbenutzer Komponenten in einer globalen Liste registriert sind, sonst kommt man nicht an die Klassen ran, wenn man lädt.
Wenn man dieses Prinzip benutzt hat man im prinzip das Verhalten der normalen Delphi VCL imitiert, was aber ausnahmsweise denke ich garnicht mal was negatives ist.

//Edit: Mir fällt gerade auf, dass das in deiner GUI dank der sich bei jedem Nachfahr verändernden Konstruktoren unmöglich ist.

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