Hintergrundbild erstellen

[DeddyH]

Auch wenn es jetzt zu funktionieren scheint, möchte ich doch einmal spezielle Engines wie Andorra 2D in den Raum werfen.

[VkPenguin]

Wie kommst du darauf, dass es funktioniert

Habe schon ein paar Sachen selbst versucht und will - wenn ich mal Zeit dazu habe - nochmal Google bemühen. Bisher bin ich noch nicht weitergekommen, habe mich nur nicht gemeldet, weil ich keine spezifische Frage hab und "hilfe!" ja nicht wirklich weiterhilft

Andorra hatte ich vor einiger Zeit schonmal im Auge, das erschien mir damals aber als zuviel Aufwand für das kleine Programm.. Jetzt ist es vielleicht nötig, ich befürchte nur, dass es sich nicht mit mSuM verträgt wie die meisten schönen Delphi-Techniken.

Vielleicht findet Popov ja auch noch was im Archiv, dann kann ich es mir da anschauen, an Codebeispielen konnte ich bisher immer am besten lernen

[Popov]

Auch wenn ich es finden würde, es waren nur Experimente, keine Engine. Also erhoffe dir nicht zu viel. Ansonsten die Api nach Clip, Rect und Rgn durchsuchen. Vor allem die Bereiche Kombinieren.

[DeddyH]

Oder mit einer Maske arbeiten und so das Vordergrundbild "ausstanzen". Vielleicht bringt das hier Licht ins Dunkel: http://www.hitekdev.com/delphi/BITMAPANIMATION.html

[VkPenguin]

Hi, danke für die Tipps. Ich verstehe die Texte zu den gesuchten Begriffen zwar noch nicht so ganz, da komme ich aber vielleicht noch hinter. Was mir gerade einfiel (wahrscheinlich funktioniert cliping auch so in der Art): Wenn ich wüsste, wie ich den Teil des Bildschirms, auf den das neue Bild gezeichnet werden soll, scanne, in ein Bild speichere und nachher zum übermalen lade müsste es doch gehen oder? Wobei ich irgendwie befürchte, dass es dann immernoch ruckeln wird, immerhin sind das ja auch unglaublich viele Berechnungen, die pro Sekunde gemacht werden müssten. Meint ihr, so könnte es funktionieren? Wenn ja, kann ich dann vielleicht Bild.LoadFromClipboardFormat nehmen?

[Popov]

Als ich DeddyHs Link oben gelesen habe, ist mir noch eine andere Methode eingefallen mit der ich auch leicht experimentiert habe. Sie ist ein Zwischending zwischen dem was ich bereits oben beschrieben habe, also alles zuerst auf eine temporäre Bitmap zeichnen und dann das gesamte Ergebnis auf die Leinwand zeichnen, und eine Lochmaske aus Regionen, was etwas komplexer wäre.

Hier ein Beispiel mit den Hausmitteln von Delphi, anhand eines Balls der sich über einen Hintergrund bewegt. Beim zeichnen wird der alte Bereich vom letzten Schritt als Rect-Bereich gespeichert, der neue Bereich, auch als Rect-Bereich. Dann wird der kleinste gemeinsamer Rect-Bereich berechnet. Alles was gezeichnet wird, wird auf diesem gemeinsamen Bereich auf der Temporärbitmap gezeichnet. Dann wird das Ergebnis übertragen. Der Vorteil hier, es wird nur das gezeichnet was sich verändert hat. Allerdings wird hier grob gearbeitet, d. h. die kleinste gemeinsame Fläche, aber auf dieser eben alles.

Auch wenn das nicht die versprochene Lochmaske ist, so ist es das Prinzip. Zerst den alten Bereich reparieren, dann das Neue zeichnen, Ergebnis übertragen.

Delphi-Quellcode:

    //das Alte merken
    RecAlt := Rect(x, y, x+Bmp.Width, y+Bmp.Height);

    ...

    //das Neue berechnen
    RecNeu := Rect(x, y, x+Bmp.Width, y+Bmp.Height);
    //kleinste gemeinsame Fläche ermitteln
    UnionRect(RecZusammen, RecAlt, RecNeu); //!Bool Funktion, Abfrage?
    //auf Temporärgrafik arbeiten
    TBmp.Canvas.CopyRect(RecZusammen, HBmp.Canvas, RecZusammen);
    TBmp.Canvas.Draw(x, y, Bmp);
    //Ergebnis übertragen
    Canvas.CopyRect(RecZusammen, TBmp.Canvas, RecZusammen);

Das ist auch eine Antwort auf deine Frage, Vergiss das Scannen und die Zwischenablage. Warum Zwischenablage wenn du das, was du kopieren möchtest, in einer Variable speichern kannst. Und warum den alten Bereich scannen, nimm doch gleich die Quelle.

[VkPenguin]

Hmm, vielen lieben Dank für Deine Mühe, aber irgendwie komme ich mir gerade schrecklich Dumm vor. Verstehe ich das richtig (Auf mein Problem übertragen):

- RecAlt ist die vohrige Position des Gegners bzw. der Rahmen darum (dafür müsste ich doch zuvor einmal den Gegner erst zeichnen oder nicht?)
- RecNeu ist die neue Position
- RecZusammen ist die Mischung aus RecNeu und dem Hintergrund (Aber wie funktioniert das Mischen? Woher weiß das Programm denn was wohin soll? Die Transparenzoptionen gehen doch im BMP-Format verloren, oder nicht? Deswegen benutzt ich ja PNG mit Transparenz)
- x ist die X-Position des Gegners
- Y " " Y- " " "
- BMP ist das Bild des Gegners (ist bei mir PNGImage, das macht aber nichts, oder?)
- TBMP ist das temporäre BMP
- HBMP ist das Hintergrundbild

Und ich müsste das ganze dann also mit *Pseudocode*

Delphi-Quellcode:

For I:=1 to Gegneranzahl Do
Begin
Altes merken
Neue Position berechnen
"verschieben"
End;

machen..? Das kann so doch nicht funktionieren ?! Bin ratlos

[Popov]

Ich glaube PNG ist ganz schlecht für ein Spiel bei dem es um Geschwinigkeit geht, dann egal welches Format man auch Windows anbietet, wenn es auf den Bildschirm kommt, ist es eine Bitmap. D. h. wenn man PNG nutzt, wird sie intern konvertiert. Sind es viele Grafiken, wird viel konvertiert. Und wenn man man 60 Durchläufe pro Sekunde hat, und hier bin ich mir nicht sicher ob das intern nur ein mal konvertiert wird oder bei jedem Aufruf, dann ist es viel Rechenarbeit.

Dabei geht es doch einfach, denn Bmp beherrscht auch die Transparenz. Einfach die transparente Farbe wählen, Transparent auf True setzten und gut ist es. Für ein Spiel ist Bmp immer vorzuziehen.

Nun zu deiner Frage: das was ich dir angeboten habe ist nicht die versprochene Lochmaske. Ich finde die alten Daten nicht mehr. Also habe ich so eine Art Lochmaske light programmiert.

Hier arbeite ich mit Rect-"Regionen" (keinen Windows-Rgn-Regionen). Noch bevor die neue Position berechnet und gezeichnet wird, wird aus den alten Werten, also die alte Region in der sich der Ball zuletzt befand, die Rect-Region als RecAlt gespeichert. Dann folgen die Berechnungen und ich berechne die Position in die gleich gezeichnet wird. Das ist die RecNeu. Nun berechne ich aus den beiden Werten den kleinsten gemeinsamen Rect-Rechteck. Nun wird per CopyRect der Hintergrund an der Stelle gezeichnet, also nicht der ganze Hintergrund, sondern nur das Rechteck. Dann wird der Ball in das Rechteck gezeichnet. Jetzt übertrage ich das Rechteck, wieder über CopyRect auf die entgültige Leinwand.

TmpBitmap dient hier nur zum arbeiten. Ich zeichne alles zuerst TmpBitmap und übertrage den kleinen Teil der geändert wurde auf die entgültige Leinwand.

Wieso der Umstand? Wenn ich zwei Bilder auf die gleiche Stelle (Hintergrund und Ball) nacheinander direkt auf die endgültige Leinwand zeichne, dann merkt man das durch flackern. Es wird zuerst das eine Bild gezeichnet und gleich danach das zweite. Auch wenn das schnell geht, man erkennt es. Also wird beides zuerst auf eine TmpBitmap gezeichnet und nur ein Bild wird kopiert.

Als du paar Posts weiter oben geschrieben hast, dass es immer noch flackert, da habe ich ein Test gemacht. Zuletzt habe ich 2000 Objekte über eine TmpBitmap gezeichnet, geflackert hat es nicht. Das Ganze ist in die Knie gegangen, so dass zuletzt die Leinwand nur noch zwei Bilder pro Sekunde erneuert wurde, also es ruckelte, aber geflackert hat es nicht.

Nun zum Nachteil der oberen Methode. Sie arbeitet immer mir dem kleinsten gemeinsamen Rechteck. Wenn aber auf dem ganzen Bildschirm sich Raumschiffe befinden dann wird schnell die ganze Leinwand zum Rechteck. Dann kann man sich auch das Berechnen sparen. Um die TmpBitmap kommst du aber nicht drumherum.

[VkPenguin]

Zunächst nocheinmal vielen Dank, dass du soviel Geduld mit mir hast, soetwas trifft man selten... Gebe mir auch Mühe

Also eins nach dem anderen: Wenn das so ist, ist BMP natürlich besser, das ist einleuchtend. Aber wenn ich mein *.png-Bild als .bmp speichern will bekomme ich die Warnmeldung: "Beim Speichern geht die Transparenz verloren. Fortfahren?", deshalb bin ich bisher davor zurückgeschreckt. Und wenn ich einfach Transparent:=True sage, woher will die Bitmap dann wissen, welcher Bereich Transparent war, wenn eben das doch verlorengegangen ist? Und - entschuldige die wahrscheinlich Dumme Frage, aber wieso soll ich eine Farbe für etwas Transparentes auswählen? Ich meine, es soll doch durchsichtig sein...?!

[Popov]

Bei der Bitmap funktioniert es mit der Transparenz so: du mußt eine Farbe opfern, die wird dann durchsichtig dargestellt. In der Praxis wird in der Regel clFuchsia genommen, man kann aber beliebige Farbe nehmen. Eingestellt wird die Farbe über Bitmap.TransparentColor := ... , dann noch Bitmap.Transparent := True setzen.

Diese Methode ist vorzuziehen, denn hier hast du die Kontrolle über die Transparente Farbe. Wenn ich mir unsicher bin welche Farbe es ist, dann mache ich es so: Bitmap.TransparentColor := Bitmap.Canvas.Pixels[0, 0]; . Hier wird erste Farbe oben links genommen. Das ist aber fast das Gleiche wie Bitmap.TransparentMode := tmAuto . Hier erkennt das System die Farbe automatisch in dem es die Pixelfarbe unten links als transparent annimmt. Wenn du also mit TransparentMode und tmAuto arbeitest, brauchst du keine Farbe zuweisen. Prüfe aber ob die Farbe korrekt erkannt wurde.