Andorra 2D [Ver. 0.4.5.1, 31.12.08]

[Codewalker]

Wäre es nicht sinnvoll (und machbar) die SpriteEngine direkt mit ShaderSupport zu versorgen? Aktuell ist es ja so, dass ein TAdRenderingObject eine Klasse und kein Interface ist, so dass man dort leider keinen TImageSprite angeben kann. Wäre es nicht möglich einen TShaderSprite zu machen, der ein Shaderskript, eine Textur und eine Normalmap erwartet und alles für den Shader nötige direkt im Sprite ausgeführt wird?

[igel457]

Da ich gerade ein Spiel schreibe, das exzessiv von Shadern Gebrauch machen wird und dazu noch die Spriteengine verwendet, werde ich sehen wie ich das am besten Einbaue.

Shader sind auf jeden Fall aber nicht an das Sprite (TImageSprite) sondern an das Bild (TImageSprite.Image) gebunden. Alle Shadereffekte sollten eigentlich direkt von TAdShaderEffect abgeleitet werden (also nicht so wie ich das in der Bumbmapping Demo mache) und sich um die Verwaltung, setzen von Properties und Laden des Shader-Quellcodes kümmern.

[Codewalker]

hm, das binden an das Bild finde ich unpraktisch. Ich programmiere ein Strategiespiel und bei der Landschaft nutze ich ein und das selbe Bild gelegentlich mehrfach. In diesem Falle würde ich ja zwei getrennte Felder auf der Landschaft verändern.
Nun, aber ich fürchte das wird wohl nicht anders gehen - verbraucht ein wenig mehr Speicher, aber das sollte nicht das Problem sein.

Wenn du das mit den Shadern in der SpriteEngine umgesetzt bekommst, sag Bescheid. Ich werde es gerne testen

[Codewalker]

Ich habe noch eine Frage zu den Window-Framworks: Bringen die (neben der Portabilität) auch einen merklichen Performance-Gewinn (so dass sich der Aufwand einer Umstellung lohnt)?

[igel457]

Die Frage ist ein wenig ungeschickt formuliert, da die Windowframeworks immer verwendet werden. Daher kann nur die Auswahl des Windowframeworks einen Geschwindigkeitsvorteil bringen.
Am schnellsten sollte das native Win32 Framework sein, da dieses die VCL überhaupt gar nicht verwendet.

[Codewalker]

Zu den Frameworks: Ich werde es mal ausprobieren. Ein paar mehr Frames wären nämlich echt gut.

Außerdem habe ich noch Verbesserungsvorschläge für den GUI-Editor: Beim Arbeiten an komplexeren GUIs kommt es immer wieder vor, dass ich nur durch anklicken Elemente minimal verschiebe. Zum Einen sollte man verhindern, das beim Auswählen direkt eine Verschiebung durchgeführt werden kann und zum anderen wäre es schon, Elemente sperren zu können. Sperren soll bedeuten, dass man diese Elemente nicht mehr in der Größe und Position ändern kann, bis man sie wieder entsperrt.
Außerdem hängt der GUI-Editor beim Starten immer in der linken oberen Ecke - wäre schön wenn die Fesnter sich ihre Größe und Position merken würden.

Edit: Noch eine Sache: Wenn man im GUI-Editor Elemente ausschneidet und wieder einfügt ist der Name wieder auf Standard ("Button3") zurückgesetzt. Ist ärgerlich, weil das erst beim Starten des Programms auffällt.

[Codewalker]

Habe noch einen kleinen Bug im GUI-Editor gefunden: Wenn man einen TAdBitmapButton im Designer auf Enabled=False stellt, kann man nach einem Test im Editor (Designmode ausschalten, testen und wieder einschalten) das Element nicht mehr auswählen. Weder per Klick, in der Baumdarstellung oder über die ComboBox im Inspektor. Man kann nur über manuelles editieren des XMLs des Element es wieder zum Leben erwecken.

[3_of_8]

So, nachdem ich lange Zeit abwechselnd keine Zeit und keine Lust hatte, hab ich mich heut mal für ein paar Stunden drangesetzt und einen PNG-Loader für Andorra geschrieben, der nach erfreulich kurzem Debugging auch zu funktionieren scheint. PNG-Sonderfunktionen wie Chromatizitäts- und Gammakorrektur werden nicht durchgeführt, da das zu aufwändig ist und ohne genaue Kentnisse über den Monitor sowieso nichts bringt - ich glaube, dass kaum ein Programm dieses Zeug wirklich benutzt.

Ich habe frecherweise im CVS die alte AdPNG.pas einfach mal überschrieben. Das hat den Vorteil, dass man sich die PNGImage.pas jetzt sparen kann und das ganze folglich auch unter Linux funktionieren sollte und den Nachteil, dass man jetzt keine PNGs mehr speichern kann - es sei denn, man greift direkt auf PNGImage.pas zu. Da ich mir allerdings kaum vorstellen kann, dass mit Andorra viele Bilder gespeichert werden, sollte das vertretbar sein. Wenn Andreas anderer Auffassung ist, kann man das ja immer noch reverten.

Um jetzt damit PNGs laden zu können, muss man eigentlich nur AdPNG.pas irgendwo in das Projekt einbinden und dann das Bild wie jedes andere laden lassen, Andorra erkennt von selbst, dass es sich um ein PNG handelt und ruft den Loader auf.

Wie bereits gesagt, alle Dateien, die ihr braucht (nämlich AdPNG.pas und AdPNGImage.pas) sind im CVS.

Sollte irgendwas nicht funktionieren, sagt mir Bescheid, ich habe das mit den exotischsten Formaten getestet, die es gibt, bis hin zu 2 Bit indizierten Schwarzweißbildern mit farbigem Hintergrund und Interlacing und es hat alles funktioniert, aber irgendwas kann man ja immer übersehen.

[igel457]

Hallo Manuel,

vielen Dank für die Bibliothek, bis jetzt scheint alles vom feinsten.

Mir ist nur ein kleiner Fehler aufgefallen. In der AdPNGImage.TAdPNGImage.ReadPixels hast du am Ende ein "Data.Free" vergessen. Habs eingefügt und lade es gleich hoch.

Es wäre zwar ganz schön wenn man die Bilder auch als PNG komprimieren (im Bilderlisten und GUI-Skins kommen halt komprimierte PNG-Bilder drin vor) kann, doch da es ja zwei Alternativbibliotheken (AdFreeImage und AdDevIL) gibt, die man im Notfall verwenden kann, ist das nicht ganz so schlimm. Ich denke die Abhängigkeit zu PNGDelphi war eine der "gravierendsten" und die ist dank deiner Bibliothek passé.

In der AdPNG.pas habe ich einen entsprechenden "work around" (deine Version hätte meine Binärdateien unlesbar gemacht) eingebaut, der die Daten einfach unkomprimiert speichert. Eine entsprechende Compilerwarnung wird ausgegeben.

Nochmal vielen Dank,
Andreas

[3_of_8]

Das Speichern wird sehr schwierig. Nicht wegen der PNG-Filterung an sich, die ist machbar, aber die Deflate-Kompression ist im Vergleich zur Dekompression - die auch nicht ganz einfach ist - relativ schwierig.