# Schnelleres Scalen



## conan2 (6. Jul 2006)

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 (6. Jul 2006)

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


----------



## lin (6. Jul 2006)

jop, mit _Image_.getScaledInstance(_int width_, _int height_, *Image.SCALE_FAST*);

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


----------



## conan2 (6. Jul 2006)

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 (6. Jul 2006)

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 (6. Jul 2006)

conan2 hat gesagt.:
			
		

> 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 (6. Jul 2006)

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 (8. Jul 2006)

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 (8. Jul 2006)

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 (8. Jul 2006)

AlArenal hat gesagt.:
			
		

> 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 (8. Jul 2006)

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 (8. Jul 2006)

Anonymous hat gesagt.:
			
		

> 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 (8. Jul 2006)

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


----------



## AlArenal (8. Jul 2006)

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 (8. Jul 2006)

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 (8. Jul 2006)

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 (8. Jul 2006)

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 (8. Jul 2006)

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 (9. Jul 2006)

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 (9. Jul 2006)

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 (9. Jul 2006)

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 (9. Jul 2006)

"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 (9. Jul 2006)

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 (20. Jul 2006)

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.


----------

