Allgemeine Technik bei Bildverdunklung in Spielen

[k3ltis]

Hallo,

meine Frage ist von allgemeiner Natur.

Stellt euch vor, ihr habt irgendein kleines 2D-Spiel mit einer Spieloberfläche mit Hintergrund und Vordergrundobjekten. Das Hintergrundobjekt ist in BufferedImage.

Grundsätzlich wird durch DoubleBUffering der ein Bild der gesamten LaufzeitUmgebung (mit samt Hintergrund und Vordergrundobjekten) erzeigt und in die Anzeige geladen.

Während des SPiels soll sich zu ebstimmten Zeiten die Helligkeit des Hintergrunds verändern (verdunkeln und wieder heller werden).

So viel zur Erklärung der Umstände...

Wir haben verschiedene Lösungsansätze des Problems theoretisch durchdacht und sind uns nicht im Klaren was davon "richtig" ist.


- 1 - Da das BackBufferBild, das in den FrontBUffer geladen werden soll grundsätzlich auf das im Hintergrund verdunkelte Bild warten muss(!) stellt man eine deutliche Verlangsamung der fps bzw der Laufzeit fest, während das Bild umgerechnet wird.

Erst haben wir versucht Pixel für Pixel dunkler zu amchen. Dann kamen wir auf die Idee eine schwarze Ebene mit einem ALphaCHannel drüberzulegen - was wohl aber auf das gleiche hinausläuft, weil die JVM die berechnung der Pixel unter der Transparenten Ebene vornehmenmuss.

Eine weitere Möglcihkeit wääre das auslegen in einen Thread... da aber der Backbuffer auf das BIld warten muss... siehe oben...

- 2 - Man lagert sämtliche Bilder der Verdunklungsanimation in eine LinkedList und speichert sozusagen jeden einzelnen Zustand der Verdunklung als eigenes BUfferedIMage, das dann einfach abgerufen werden kann... macht man das überhaupt so???

Wir fragen uns, warum eine simple Bildverdunklung einer relativ kleinen Grafik so unglaublich lange dauert, dass man es förmlich sehen kann, wohingegen moderne 3D-Shooter rebungslos laufen obwohl die Berechnungen, dort in keienr Weise mit diesen hier zu vergleichen sind...

Eine Referenz auf eine entsprechende Erklärung würde uns schon reichen

Mfg
keltis

 

[Marco13]

Dann kamen wir auf die Idee eine schwarze Ebene mit einem ALphaCHannel drüberzulegen

Das wäre jetzt er erste Ansatz, den ich in betracht gezogen hätte. Das sollte sehr schnell sein, und vor allem: DEUTLICH schneller, als mit einzelnen Pixeln ruzufrickeln!

Poste ggf. mal ein paar Zeilen suggestiven Code, was da so gemacht wird...

 

[k3ltis]

Nabend,

ich versuche mal sporadisch das zu erklären, was passiert.

class Environment {

method render() {
/*
 * ruft bei Bedarf die Methode transformBrightness() auf (z.b. wenn es von der
 * Tageszeit her dunkler werden soll.
 *
 */
}

method transformBrightness(BufferedImage, float) {

float[] scaleFactors = {brightness, brightness, brightness}; 
float[] offsets = {0.0f, 0.0f, 0.0f};
RescaleOp brightnessOp = new RescaleOp(scaleFactors, offsets, null);
return brightnessOp.filter(image, null);

/*
 * So 100% verstehe ich zwar nicht, was da genau passiert, doch der "pseudoCode"
 * von RescaleOP gibt aufschluss darüber, dass jeder Pixel des zu verändernden Objekts
 * aufgerufen und neu berechnet wird.
 *
 * Das, was dabei rauskommt wird an die Methode render() zurückgegeben und abgebildet.
 *
 */

}

}

Weitere Informationen:
Die Klasse Environment ist eine Erweiterung von JPanel und wird in einer MainClass (, die auch die MainMethode beinhaltet) aufgerufen. DIese MainClass ist eine Erweiterung von JFrame.

Also im Klartext habe ich das so verstanden:
Der Hintergrund wird bei Bedarf in der Methode transformBrightness(...) Pixel für Pixel neu berechnet.

Um gleich eine Unklarheit vorweg zu nehmen:
Wenn man mit einer schwarzen Fläche mit AlphaChannel vor dem eigentlichen Hintergrund arbeitet, muss die JVM doch ebenfalls jeden einzelnen Pixel, der unter der durchsichtigen Fläche liegt mit dem jeweiligen Farbwert der transparenten Fläche neu berechnen!? Warum sollte das schneller sein?

Grüße
k3ltis

 

[bERt0r]

Weil die JVM unter umständen diese Arbeit an die Grafikkarte auslagern kann.

 

[k3ltis]

Ok, das klingt ganz gut; Danke jedenfalls.

WIe steht es mit der Idee die Bilder einzeln in einer LinkedList zu speichern...? Ist sicherlich keine gängige Methode.

Im Allgemeinen verstehe ich nicht, wie es sein kann, dass eine einfache Hintergrundberechnung generell so lange dauern kann. Man schaue sich bloß ein paar moderne 3D-Shooter an... die Lichteffekte im Einklang mit der SPielephysik... das kostet doch sicherlich viel mehr Berechnungskapazität. Was ist da anders?

Gruß
Keltis

 

[Marco13]

Der Vergleich mit 3D-Shootern ist schwierig. Das läuft ja alles in Hardware, auf der Grafikkarte. Da hat man "nur noch" einen Großen Memory-Klumpen mit Geometrie und Texturen, und schickt das ganze an die Grafikkarte, die mit einen Haufen höchst-komplizierter Shader da was schönes draus macht....

Ein Bild zu zeichnen und dort ein Alpha-Rechteck drüberzulegen sollte eine praktisch nicht messbare Zeit benötigen.

Die Bilder in einer Liste zu speichern ist theoretisch möglich, aber sollte bei so einer einfachen Rechnung nicht merklich schneller sein - aber braucht natürlich deutlich mehr speicher. Bei "komplexeren" Operationen am Bild könnte man sowas in Erwägung ziehen, aber man sollte sich genau überlegen, ob der Trade-Off zwischen gesparter Rechenzeit und höherem Speicherbedarf es wert ist...

 

[k3ltis]

Ok,

vielen Dank Leute!