Saving transformed Images? And interpolation! Rotate Rotate Rotate

Ok so long story short the JOGL api gave me to many seizers so I have switched to java2D in hope of porting it to jogl later. Unfortunately that benefit of JOGL was some awesome performance averaging around 3% on my computer. Now that I’ve switched to java2D its averaging around 70%.

Anyway the problem.

Right now every loop the game calls:



affineTransform.rotate(Math.toRadians(this.rotation), image.getWidth(null)/2, image.getWidth(null)/2);


To rotate the “player”. I was wondering if I could save all the rotate instances when the game loads thus reducing the epic load on the game loop.

Also the background is smoothed out by interpolation(I think) which I stumbled upon by accident so if anyone know about how much processor power it requires?

Anyway I’m new so go easy.

Thanks to Kevin Glass for those tuts. After I stumbled upon them, this has become a bit of a hobby.


http://img140.imageshack.us/img140/1535/postkp8.png

since your using java2d why not try the slick library, should be fairly easy to port and you will get the awesome performance of opengl with java2d style api.

http://slick.cokeandcode.com/

I’m keen to once I have the basic game done, but until then I’ll stick with java2d. I’m still trying to sort out the class structure and what not. I’m having to refractor the game a lot cough.
Guess if it does get worse I’ll switch over. I’ve had a brief look at slick and its api might see if I can find some examples.

You could save transformed images as you suggested, but if the images are
translucent (not bitmask or opaque) you won’t get them hw accelerated unless you run on
6u10 on windows (where the new d3d pipeline is enabled by default).

Dmitri

The following is a code snippet I just made which rotates your image a variable number of times. Each rotation is a new BufferedImage. Doing this will take up more RAM, but is a one-time cost on the processor. It’s a trade-off. :-\


BufferedImage[] shipImages = new BufferedImage[NUMBER_OF_IMAGES];

public void loadShipImages()
{
     float increment = 360.0f / NUMBER_OF_IMAGES;
     BufferedImage originalImage = null;

     try
     {
          originalImage = ImageIO.read(new File(IMAGE_LOCATION));
     }
     catch (Exception e)
     {
          e.printStackTrace();
          return;
     }

     for (int i = 0; i < NUMBER_OF_IMAGES; i++)
     {
          BufferedImage b = new BufferedImage(originalImage.getWidth(),originalImage.getHeight(),BufferedImage.TYPE_INT_ARGB);
          Graphics2D g2 = b.createGraphics();
          g2.drawImage(originalImage,0,0,originalImage.getWidth(),originalImage.getHeight(),null);
          g2.rotate(i*increment,b.getWidth()/2,b.getHeight()/2);
          g2.dispose();
          shipImages[i] = b;
     }
}

Note that you may need to increase the size of BufferedImage b when you create it. If you see your image getting trimmed, that’s the problem. At a 45 degree rotation, the corners of a rotated square will all be outside the original bounds of that square. You can calculate the maximum possible dimensions with geometry, but you probably don’t need to worry about that if you’re doing just one image.

Imports:
ImageIO = javax.imageio.ImageIO
Graphics2D = java.awt.Graphics2D
BufferedImage = java.awt.image.BufferedImage
File = java.io.File

Googled it “6u10” and found : http://java.sun.com/javase/downloads/ea/6u10/6u10beta.jsp

Beta apparently so I’ going to assume I’m not using it at the moment.

As far as I know I’m using JDK 1.6

Thanks for the reply been waiting for some of the hardcores to come out of the woodwork.

Cheers the code has been very helpful possibly exactly what I was looking for.

I’m use to using java.awt.Image; rather than buffferedImage so I’ll try it with that.

Anyway thanks all.

Awesome forum.

You can also rotate your graphics context instead of using AffineTransform, not sure if that will be much faster or not. You may want to give it a go.

I’ll have to do some tests.

affineTransform.rotate Vs. Graphics2D.rotate ???

The images are so small the amount of ram they will use is irrelevant when its currently using needing so much of the processor.

I’m confused - you say you’re still sorting out the class structure, yet you are wasting time putting in performance optimisations that are redundant as soon as you stop using Java2D?

While it’s a nice api, I would suggest you forget J2D, too many operations are unaccelerated in the current (public) release.
As kapta has already suggested, slick is the perfect alternative.

Ha does sound like a bit of a contradiction.

I’m not fine tuning the performance its more like getting out the kinks. Like some of the order m^n functions.

Sounds like I better just get on with it and switch to slick.

http://img247.imageshack.us/img247/9862/nebularj2dqx3.png