Panel Manipulation

Hallo JCL, sorry, ich muss mal wieder auf mein altes Problem mit Panel-Auf-Ab-Umblendungen kommen.

Folgende Ausgangslage.

PANEL* Wald=
{
//Hintergrundbild
bmap=Baumwipfel; //1024*768

//animierte Eule
windows(100,100,200,200… Eulenanimation) //200*200 Körper
windows… // Augen…
}


Ich habe einen Panel mit einem 1024*768 Hintergrundbild (viele Baumwipfel).
In diesem Panel soll ein Tier animiert werden. Dieses realisiere ich über viele Windows im gleichen Panel. Die Bildfragmente liegen also über dem Hauptbild.

Wenn ich jetzt den Panel abblende, dann wird das Hintergrundbild gegen alpha 0 gesteuert, mitsamt alles Bildelementen des animierten Tiers.
Jetzt passiert logischerweise folgendes:
Im Bildbereich x100 y100 bis x300 y300 addiert sich der Farbwert des Windows Blendzustand alpha z.B. 40 mit dem Hintergrundbild in diesem Bereich.

Daraus folgt, dass ich bei den Blendungen hellere Bildbereiche habe, nämlich immer da, wo
sich windows überlagern mit anderen Bildelementen.

Ich kann bei Auf und Abblendungen tricksen, in dem ich einen Panel mit schwarzem Bmp in einem größeren Layerbereich auf und ab-fade.

Wenn ich aber eine Überblendung machen will, zwischen 2 Paneln, dann funktioniert das nicht mehr.

Ist es möglich, dass die Engine solche Bereiche, in denen sich 2 Bildbereiche beim fading farblich addieren einfach mitkalkuliert und entsprechend in diesem Bereich einen höheren Transparenzwert zeichnet?

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////
Problem 2.
Ich habe ein window mit einem Tier
Darüber eine needle, die einen wackelnden Schwanz darstellt.
Darüber ein window mit einem Busch.

Also
Window Tierköprfer
Needle Schwanz
Window Busch.

Trotzdem wird die needle über dem Busch gezeichnet. Werden needles immer über Windows gezeichnet? Hab noch nicht das Handbuch gelesen.

Beim Faden mehrerer Objekte übereinander addieren sich natürlich die Farben. Sie brauchen daher für das Window einen schwarzen oder transparenten Ausschnitt. Wenn das Eulenbild nicht rechteckig ist, geht Ihre Methode gar nicht - in diesem Fall müssen Sie es per Pixelbefehl direkt in das Waldbild hineinzeichnen. Dann können Sie auch überblenden.

Die Reihenfolge von Panel-Elementen ist so, wie man sie normalerweise braucht, d.h. Needles stets über Windows. Wenn Sie es anders brauchen, nehmen Sie für die Elemente separate Panels.

Auf dem Hintergrundbild einen schwarzen Abschnitt zu erstellen, um darauf praktisch ein drüberliegendes "Puzzle-Teil" einzufügen, ohne Alpha-Kanal - klar, das funktioniert. Dann würde keine Addition der Farben mehr stattfinden.
Wenn aber bei Zeichentrickelementen nicht nur ein Alpha-Kanal existiert, sondern dazu noch das Element verschoben wird - stehe ich voll mit dem Rücken zur Wand. Das Problem existiert wie gesagt nur bei Überblendungen.

Ich habe mich nur gefragt, ob es möglich wäre, dass die Engine diese doppelten Pixelbreiche praktisch überprüft und entsprechend beim Fading korrigiert.
Was zwar möglich wäre, aber bei der Anzahl der Bildpunkte scheinbar zu Rechenproblemen führt.... wenn ich das als Laie richtig verstehe.

Und noch ein Vorschlag, Idee, Denkanstoß..
Die Needle wird zwar allgemein für Zeiger verwendet, wenn ich aber eine Zeichentrickfigur erstelle, möchte ich die möglichst in einem Panel unterbringen. Einfach der Übersichtlichkeit wegen und dass ich bei Animationen und auch Positionsverschiebungen nicht ins totale Panel-Chaos verfalle.

Wenn ich Elemente rotieren lassen will (wie z.B. den Wolfsschwanz oder eine Windmühle) - dann kann ich auch die Needle verwenden - weil ich normale windows ja eben nicht rotieren lassen kann. Und darum wäre eine Berücksichtigung von windows über needles sehr brauchbar.

Unter Future habe ich den pan_setrot-Befehl vorgestellt. Der wäre sehr brauchbar.

Engines überprüfen keine Pixelbereiche, zumindest nicht mehr seit 1980. Damals gab es Hardware-Überblendmaschinen, die zu diesem Zweck eine schwarze Maske in den Hintergrund stanzten. Heute geht das per Blit-Operation mit Pixelbefehlen, oder mit einem 2D-Shader, oder z.B. mit einem Panel-Rendertarget.

GUI-Bedienelemente wie Needles und Windows sind für Animationen denkbar ungeeignet. Auch wenn das ginge, ergäbe das eine chaotische Softwarestruktur. Verwenden Sie der Einfachheit halber für animierte Elemente entweder stets ganze Panels, die Sie beliebig rotieren können, oder erzeugen Sie die Animation gleich direkt per Blitoperation.

Danke, wie ich oben schon bemerkt habe, bin ich ein Laie, was die Programmtechnologie angeht. Unter "blitoperation" fand ich bei google als verständlichste Ausführung nur eine medizinische Maßnahme. Können Sie mir bitte auf die Sprünge helfen, wo ich das vorgeschlagene Verfahren recherchieren kann? Oder wie ich es in einem gs-Projekt einsetzten kann? Danke.

http://manual.3dgamestudio.net/bmap_blit.htm

http://manual.3dgamestudio.net/apixel_to_bmap.htm

http://manual.3dgamestudio.net/bmap_process.htm

http://manual.3dgamestudio.net/target_map.htm

Mit target_map kannst du ein gedrehtes Panel auf ein anderes draufrendern, das ist vermutlich was du brauchst.

Was hälst du davon, draw_quad für deine Figur samt Animation zu verwenden? Dann kannst du auch auf den Einsatz von "needle" und co verzichten, da die Anweisung Rotationen (sowie Transparenz) unterstützt. Desweiteren lässt sich so zuerst schwarz über das Hintergrundpanel zeichnen (entweder im Rechteck ohne BMAP oder aber mit deiner Figur noch einmal komplett in schwarz), um durch einen nachfolgenden draw_quad-Befehl ein sauberes Blenden deiner Figur zu ermöglich.

Danke, vielen Dank. RTFM, okay.

Tut mir leid, wenn ich noch einmal was zu dem Thema fragen möchte.
Ich verwende nach wie vor für mein Zeichentrickspiel die aus Ihrer Sicht ungeeigneten window- und needle-Methoden. Jetzt habe ich bemerkt, dass mein alter Dell-LTop bei Bildformaten über 2048 die Animation falsch darstellt und Schwenks über eine Bildfläche von 2048 nicht möglich sind, b.z.w. die Bilder verzerrt darstellt. Also habe ich die wenigen Bilder aufgeteilt und Animationsphasen aufgeteilt.

Jetzt frage ich mich als technischer Laie… was für technische Tücken könnte es noch geben?
Die Bilder sind jetzt alle maximal 2048*768, alles funktioniert einwandfrei…
Muss ich noch was beachten in Bezug auf Rechner heute und Altrechner, Stand 2000?

Bei ganz alten Rechnern sollten Sie sich sogar auf 1024 beschränken, bei Rechnern ab Stand 2002 ist 2048 normalerweise ok. Lesen Sie die Hinweise im Handbuch zu Texturformaten und -Größen.