BufferStrategy vs. paintComponent

[Raziell]

Hallo zusammen,
momentan stellt sich für mich die Frage, welches der genannten Prinzipien ich für mein zukünftiges Vorhaben anwenden soll.
Beim Vorhaben handelt es sich um eine Tilemap für ein Echtzeit RPG.

In der Vergangenheit habe ich klassischerweise die paintComponent überschrieben und dort gezeichnet.
Im Internet konnte ich leider keine brauchbare Gegenüberstellung der beiden Varianten finden.
Was sind denn die Vor- bzw. Nachteile der beiden Varianten?

PS: Engine bzw. Framework kommt erstmal nicht in Frage.


Danke

 

[aze]

Hier gibt es einen Vergleich:

PDF

http://idisk.mac.com/han.solo-Public/Presentations/ForgottenPowerOfSwing/ForgottenPowerOfSwing.pdf


Video:

http://rheinjug.de/videos/gse.lectures.app/Talk.html#TheForgottenPowerofSwing

 

[HotWax]

Hey, ich hätte auch Fragen zum Thema!

bei deinen gepostetet Links geht es ja darum die das in der paintComponent() Methode lediglich der drawImage Teil steht. Das eigentliche Graphische wird in einer separate Methode ausgelagert oder? Hat das den was mit BufferStrategy zutun?


Noch eine Frage von mir bezüglich paintComponent():
Ich habe nach gelesen das man immer painComponent() überschreiben sollte, nicht paint() vom Frame. Aber warum? Wenn ich jetzt ein Spiel machen würde das im Full-Screen läuft, würde ich das Graphische dann im paint() zeichnen lassen, oder ein Panel in das Frame einfügen und dort mittels paintComponent() alles zeichnen lassen? Wenn das so ist, warum?

Ich hoffe ihr könnt mir das Erklären

 

[Raziell]

Hi,
man sollte immer die paintComponent() einer JComponent überschreiben. Optimal die eines JPanels. Warum genau kann ich dir leider auch nicht sagen aber es ist so

Das ganze sollte ungefähr folgendermaßen aussehen:

@override
	public void run() {
		while (running) {
			doLogic();
			moveObjects();
			repaint();
			try {
				Thread.sleep(10);
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}

	}	

@Override
	public void paintComponent(Graphics g) {
		super.paintComponent(g);

		g.drawImage(imgBackround, 0, 0, this);
		
		for (Drawable draw : actors) {
		     draw.drawObjects(g);
		}
	}

Guter Einstieg in das Thema -> Quaxli's Tutorial. Findest du über die Suche.

Buffer Strategy verfolgt ein etwas anderes Prinzip. Da findest du aber auch Beispiele hier im Forum.

Aber wenn noch jmd. Tipps bzw Quellen zum Thema paintComponent vs. BufferStrategy hat her damit

Danke

 

[HotWax]

Hallo,

ich habe gerade etwas nachgelesen und herausgefunden das man das Grafische einmal mit paint()/paintComponents() machen kann und mittels BufferStrategy. Dachte vorher man das man bei BufferStrategy trotzdem paint() überschreiben muss.

Jetzt verstehe ich auch die Frage des Thema's und mich interessiert der Vergleich natürlich auch

Trotzdem bleibt noch meine Frage:

Noch eine Frage von mir bezüglich paintComponent():
Ich habe nach gelesen das man immer painComponent() überschreiben sollte, nicht paint() vom Frame. Aber warum? Wenn ich jetzt ein Spiel machen würde das im Full-Screen läuft, würde ich das Graphische dann im paint() zeichnen lassen, oder ein Panel in das Frame einfügen und dort mittels paintComponent() alles zeichnen lassen? Wenn das so ist, warum?

Und ist der super.paint() bzw super.paintComponents() immer notwendig?

Liebe Grüße

 

[Raziell]

Hey,
Wie bereits erwähnt, paint sollte man nicht überschreiben! Auch sollte man nicht paintComponents sondern paintComponent uberschreiben.
Ja der super Aufruf ist nötig in diesem Fall.
Wie gesagt über die forum suche findest du einige codebeispiele von Benutzern zum Thema BufferedStrategy.
So wie ich es momentan beurteilen würde, würde ich sagen, dass BufferedStrategy der bessere weg ist.

 

[Ein Keks]

Mit BufferStrategy lässt sich sogennantes active rendering realisieren, sprich du zeichnest die GUI selbst neu, wohingegen das Überschreiben von paintComponent() passive rendering darstellt, sprich das Betriebssystem dafür verantwortlich ist wann etwas neu gezeichnet werden wird (z.B wenn man das Fenster resized). Das Problem mit passsive rendering ist das man keinen direkten Einfluss darauf hat wann etwas neugezeichnet wird, man kann höchstens mit repaint sagen, dass sich die GUI demnächst mal neuzeichnen soll, wobei teilweise mehrere repaints zusammengefasst werden, was bei Spielen nicht umbedingt gewünscht ist.
Active Rendering macht also dann Sinn, wenn man mehr Kontrolle darüber haben will, wann (und wie) etwas neugezeichnet werden soll (z.B wenn man soetwas wie page-flipping statt DoubleBuffering verwenden will)
Hier auch nochn kleiner link

 

[Quaxli]

Eine lesenswerte Quelle dazu ist meiner Ansicht nach "Killer Game Programming" (englisches Tut).
Hier ist der Link: Killer Game Programming in Java

Die ersten paar Kapitel, die man als PDF ansehen kann beschäftigen sich sozusagen mit den Grundlagen von Spieleprogrammierung, wie Optimierung der FPS durch Anpassung des GameLoops. Unter anderem wird auch auf aktives Rendern eingegangen. Insgesamt sehr lesenswert.

 

[Kr0e]

Nur ein kleiner Tipp am Rande... Nimm kein Java2D für sowas... Es gibt gute OpenGL libs dafür. Mein Tipp: Slick!
DAs ist eine 2D OpenGL Java Game Library. Alles drin geregelt wie z.B. Sound, Input, Grafik. Ich hab von einiger Zeit auch mal ein 2D Jump'n'Run netzwerkspiel gemacht... Unter Windows ist Java2D recht gut, aber unter Mac und Linux fäntg alles schnell an zu ruckeln... VolatileImage klappt unter manchen Macs garnicht, gleiches gilt für Linux. Java2D ist gut genug für GUI aber lass bei Spielen die Finger davon

Gruß,

Chris

PS: Slick wird dir gut Gefallen, da die sich bemüht haben, extra für Java2D Leute einen guten Umstieg zu gewährleisten. Es gibt auch auch Graphics-Objekt zum zeichnen von primitiven usw...

 

[Raziell]

Hi,
ja eigtl. wollte ich keine externen Libs benutzen aber ich glaube du hast Recht und es macht wirklich Sinn, Slick etc. zu benutzen anstatt alles selbst zu implementieren.