Does AffineTransform Cost much to use?

Java 2D
#1

Hey people!

I have just made a big structural change in my game and its graphic system, so now i have accelerated graphics instead of using Toolkit and Image.

By having this i thought that AffineTransform might be a nice thing to use instead of pre rendered graphics for rotation of tiles, so i implemeted this in the game, but i have also done quite more stuff to the system.
The thing now is that the game is very slow, and i dont really know whats slowing down the system, is it AffineTransform or is it the way i render things?

Heres a code snippet on the tile renderer, what do you think is wrong, and what can slow down the system?


	public void draw(Graphics2D g)
	{
		Graphics2D gTiles = (Graphics2D) g.create();
		if(transform != 0)
		{
			if(transform == 1)
				gTiles.rotate(1.5707963267949d, pos[0]+(size[0]/2), pos[1]+(size[1]/2));
			else if(transform == 2)
				gTiles.rotate(3.1415926535898d, pos[0]+(size[0]/2), pos[1]+(size[1]/2));
			else
				gTiles.rotate(4.71238898038469d, pos[0]+(size[0]/2), pos[1]+(size[1]/2));
		}
		if(id == 1)
			image = concrete1;
		else if(id == 2)
				image = concrete2;
		else if(id == 3)
				image = concrete2_c;
		else if(id == 4)
				image = concrete2_cc;
		else if(id == 101)
				image = wall1;
		else if(id == 102)
				image = wall1_c;
		else if(id == 103)
				image = wall1_cc;
		else if(id == 201)
		{
			if(frame == 0)
					image = dorr1f1;
			else if(frame == 1)
					image = dorr1f2;
			if(frame == 2)
					image = dorr1f3;
		}
		gTiles.drawImage(image, pos[0], pos[1], size[0], size[1], null);
		gTiles.dispose();
	}

Maybe its because i create a new Graphic2D object each time i render a tile or what can it be?

#2

Comment out the lines where you rotate, see whether the program is still slow.

On another note:
By all means use identifiers instead of literals. Math.PI and so on instead of 3.14… . And instead of id == 104, then write id == concreteID2, such that you don’t have any “magical numbers” in the code.

#3

Affine transforms weren’t hardware accelerated in jdk 5.0 (and earlier jdks) unless you use opengl pipeline.
So it is entirely plausible that the slowdown is caused by using transforms because
we’d have to use the software loops to do the transformation, which could be quite slow
if one of the images (src or dst) is in video memory.

You can try the d3d or opengl pipeline in mustang and see if that improves
the performance (-Dsun.java2d.d3d=true and -Dsun.java2d.openg=True respectively).

Dmitri
Java2D Team

#4

Hey Dmitri!

I just figured out yestoday how to enable the opengl pipeline, before i thought that this were a general setting so that you just could write “java -Dsun…” but yestoday i reallised that this werent the case, so now i run the game with opengl enabled and the framerate is at a steady 50fps =)

It made all the differance!

Hjort <- The opengl pipeline fixed all my troubles =) will try to get better id tags on the tiles, the game is at a early stage så why i have first 1,2,3,4 and then i jumps to 101 and so on is because the collision function checks if a tile is larger than 100, if so then the tile is collideble (ie. a Wall or a door), i have the collide data embeded in the Tile class now, but i havent implemented it in the game yet, this will be done soon thohug giving space for better id tags…

#5

The pipeline is great, but at least on my laptop the drivers are not that happy about it. If you can, you should try to make it run well without the pipeline and let the pipeline be an option. Since you only rotate in multiples of ½pi, you could store 4 images for each type of tile - just generate them when the game loads - then render them without any transformation.