Schnelleres Scalen

[conan2]

Mir ist aufgefallen dass das Scalen von vielen Bildern mit AffineTransform die Geschwindigkeit ganz schön drosselt. Gibt es da eine schnelle Möglichkeit?

 

[The_S]

kA ob das schneller is, aber es gibt die Methode von Image getScaledInstance. Da kannste auch nein Skallierungsmodus mitangeben (fein, schnell, normal, ...)

 

[lin]

jop, mit Image.getScaledInstance(int width, int height, Image.SCALE_FAST);

natürlich geht das zu Lasten der Bildqualität.

 

[conan2]

wow thx genau was ich gesucht hab

EDIT: Wohl doch nicht ganz was ich gesucht hab... jetzt ruckelt das Spiel nicht nur aufs Übelste, sondern blinkt sogar ganz schlimm, obwohl ich BufferStrategy benutze! Und das einzige was ich verändert habe, ist, dass ich statt

g2.drawImage(img,transform,this);

jetzt

g2.drawImage(img.getScaledInstance(img.getWidth()*scale,img.getHeight()*scale,Image.SCALE_FAST),transform,this);

schreibe! Was mach ich da falsch?
Im AffineTranform wird übrigens nur die Translation gesetzt.
Zu erwähnen sei vielleicht noch, dass die Methode umgefähr 300x pro Sekunde verwendet wird, ist das zuviel? Denn eventuell könnte ich das Scalen auch weglassen, aber dann entsteht halt keine so schöne dreidimensionale Illusion mehr wenn ein Gegenstand der Kamera näher ist als der andere.

 

[Brainiac]

jetzt transformierts du das scalierte Bild. Also noch mehr aufwand alsvorher. Lass einfach das transformieren weg, und übergib das skalierte Bild direkt zum zeichnen.

 

[Roar]

Zu erwähnen sei vielleicht noch, dass die Methode umgefähr 300x pro Sekunde verwendet wird, ist das zuviel? Denn eventuell könnte ich das Scalen auch weglassen, aber dann entsteht halt keine so schöne dreidimensionale Illusion mehr wenn ein Gegenstand der Kamera näher ist als der andere.

vielleicht solltest du dir mal überlegen wie sinnvoll das ist, denn
a. kannst du ein bild nicht 300 mal in der sekunde skalieren *und* auch noch darstellen.
b. ich hoffe mal du skalierst nicht immer das selbe bild/die selben bilder ja? denn wenn ja: selbst schuld
c. ist dir hoffentlich klar, dass das menschilche auge gar nicht soviele bilder pro sekunde wahrnehmen kann, und es deshalb egal ist ob du versuchst die animation (denke ich mal?) in schritten von 300 bildern, 1000 bildern oder 50 bildern pro sekunde ablaufen zu lassen :autsch:

 

[AlArenal]

zu c:

Du wirst auch lange suchen müssen, ehe du eine Grafikkarte oder nen Monitor findest, die 300 Hz machen

Geh mal für nen guten TFT von ner Umschaltzeit voln 20ms für farbige Pixel aus, dann biste bei max. 50 Bildwechseln pro Sekunde.

 

[conan2]

Ne, ganz so ist es nicht, ich habe ca. 30 fps, aber es werden mehrere Bilder skaliert, oft auch mehr als zehn.

jetzt transformierts du das scalierte Bild. Also noch mehr aufwand alsvorher. Lass einfach das transformieren weg, und übergib das skalierte Bild direkt zum zeichnen.

Also meinst du es wäre schneller, das Bild einfach mit der Graphics2D.drawImage(img,x,y,this) zu zeichnen als mit der AffineTransform-Methode, die das Bild aber so nur transliert?

b. ich hoffe mal du skalierst nicht immer das selbe bild/die selben bilder ja? denn wenn ja: selbst schuld :wink:

Wie meinst du das? Es ist u.A. schon auch das gleiche Bild, das am Bildschirm ist, und halt mehrere Instanzen davon, alle mit anderen Z-Tiefen, die sich jeden Frame ändern.

Falls es was hilft, die Methode, die das ganze zeichnet:

private void paint() {
	Graphics2D g2 = (Graphics2D) strat.getDrawGraphics();
	g2.setColor(getBackground());
	g2.fill(new Rectangle2D.Double(0, 0, getWidth(), getHeight()));
	Drawable[] sorted = items.toArray(new Drawable[items.size()]);
	Arrays.sort(sorted, new ZComparator());
	for (int i = 0; i < items.size(); i++) {
		double scale = foc / (foc - sorted[i].getZ() + cam.getZ());
		double x = o_x
				+ (sorted[i].getX() - cam.getX() - sorted[i].getImage()
						.getWidth() / 2) * scale;
		if (x > -sorted[i].getImage().getWidth() && x < WIDTH) {
			double y = o_y
					+ (sorted[i].getY() - cam.getY() - sorted[i].getImage()
							.getHeight() / 2) * scale;
			if (y > -sorted[i].getImage().getHeight() && y < HEIGHT) {
				AffineTransform at = new AffineTransform();
				at.setToTranslation(x, y);
				Image img = sorted[i].getImage();
				g2.drawImage(img, at, this);
			}
		}
	}
	strat.show();
}

Hier ist mal eine Test-version des Spiels: http://rapidshare.de/files/25254758/Katamari.rar.html
Und falls es jemanden interessiert, hier noch der Sourcecode: http://rapidshare.de/files/25255301/Katamari_Source.rar.html

 

[AlArenal]

Ich weiß ja nicht mit welcher 3D-Lib du arbeitetst und bin da auch nicht wirklich fit drin, aber ist es nicht so, dass du das Bild einfach als Textur auf eine Fläche/ein Objekt legst und sich die Lib automatisch um die Skalierung kümmert und das in der Regel hardware-beschleunigt (über OpenGL, u.ä.)?

P.S.:
Das ist ne Adaption von irgendeinem Konsolenspiel, oder?

 

[Leroy42]

Das ist ne Adaption von irgendeinem Konsolenspiel, oder?

Seit wann können Konsolenspiele etwas adaptieren :shock:

Sorry, im Voraus aber:

[schild=10 fontcolor=000000 shadowcolor=C0C0C0 shieldshadow=1]Hab heute meinen Frusttag![/schild]

 

[Guest]

lol? 3d-lib? hardware beschleunigt? ... ...
Also eigentlich benutz ich nur das Standard-JDK 5.0 mit nix drum und dran und zeichne alles mit den Graphics2D
Ist das schlecht?^^

Jop soll mal eine Adaption von We love Katamari werden

 

[AlArenal]

lol? 3d-lib? hardware beschleunigt? ... ...
Also eigentlich benutz ich nur das Standard-JDK 5.0 mit nix drum und dran und zeichne alles mit den Graphics2D
Ist das schlecht?^^

Naja, es erklärt zumindest hier und da die Performanceprobleme

 

[conan2]

öhm... und was gäbs da für eine Alternative?

 

[AlArenal]

Schau doch mal hier: http://www.java-forum.org/de/viewforum.php?f=25

Wobei ich derzeit JOGL für die performanteste Alternative halte.

 

[conan2]

Sry wenn das nicht ganz zum Thema passt, aber ich hab mal J3D installiert und es hat funktioniert. Dann hab ich die jMonkey-Engine genau nach der seitenlangen Beschreibung installiert und es hat nix funktioniert. Ist das bei JOGL so wie bei J3D dass man es nur installieren braucht oder muss man alles manuell machen wie bei der jMonkey-Engine?

 

[AlArenal]

Kann ich dir nicht sagen, weil ich keine gerade erst zum ersten Mal von jMonkey höre. Schau dir doch mal die Demos auf der JOGL-Site an, ebenso wie dessen Forum. Für JOGL isses eigentlich nur ne Sache einer DLL (Windows), bzw. einer JAR-Datei.

 

[conan2]

k, dann werd ich mal schauen ob ich zu JOGL eine umfangreiche Dokumentation find, bei J3D gibts ja eine gute, sogar auf deutsch. Kennst du da vielleicht irgendwas?

 

[AlArenal]

Ich hab hiern Buch liegen, aber das ist weder aktuell noch gut. Wer mit JOGL arbeitet, für den ist JOGL selbst nicht so tragisch, sondern OpenGL. JOGL ist lediglich ne Schnittstelle für OpenGL.

www.opengl.org

 

[conan2]

Also da ich mich mit diesem Thema so gut wie gar nicht auskenne, kann ich dir da nicht ganz folgen. Wie meinst du das "JOGL ist nicht tragisch, sondern OpenGL"? Ich hab mich ein wenig auf der Seite umgesehen und irgendwie entsprichen die OpenGL-Anweisungen ziemlich genau den JOGL-Funktionen die bis jetzt gesehen hab...

 

[AlArenal]

JOGL selbst ist kein aufgeblasenes oder super-abstraktes Framework, sondern ein, wie du selbst schon gemerkt hast, recht nache an OpenGL selbst angesiedeltes Bindeglied. Um mit JOGL arbeiten zu können, muss man sich in erster Linie mit OpenGL auseinandersetzen.

 

[conan2]

Also hab ich das richtig verstanden, dass JOGL eine Java-Extension ist die nichts anderes tut als mit Methoden gleichnamige native C-Funktionen aufzurufen?

 

[AlArenal]

"nichts anderes" wäre untertrieben, weil es ja schon ein objektorienteirter Wrapper um die nicht objektorientierten OpenGL-Aufrufe ist. Aber wer sich nicht mit OpenGL beschäftigt, wird mit JOGL nicht viel reißen können.

Leider gibts nur ein Buch zu JOGL. Komm aber gar nicht erst auf die Idee es dir zuzulegen. Das Ding ist so dermaßen mies...

 

[conan2]

Ich hab mich mal ein wenig umgesehen und hier was gefunden:
Die Tutorials hier sind für C++: http://nehe.gamedev.net/
Und hier gibts den Source-Code für alle Lessons für JOGL adaptiert: http://pepijn.fab4.be/?page_id=34
Ich denk mal es sollte zu schaffen sein aus den OpenGL-Lessons und dem Java-source-code das Wichtigste für mich rauszuholen. Das Buch wäre dann halt der letzte Ausweg :roll:

 

[Mac Systems]

Letzter ausweg ? das Buch ist Pflicht meiner meinung nach, am besten man kauft sich das neue Red Book zu OpenGL danach hast du weder grosse probleme mit JOGL oder LWJGL. Beider Frameworks nutzen halt NIO buffer anstatt pointer.