Rotate image

Java 2D
#1

Hello

I’m trying to make a 2D space game where each object is built up by an Image.

The problem is that I want the objects to be able to rotate. So I’ll need some way of rotating the object images.

I have understood that since Graphics2D.rotate() is really slow I’ll need to pregenerate the rotated version of the object image.

Could someone show how to do this? I’m using java.awt.Image and not BufferedImage.

And since my collision detection system works with the bounding boxes of the images I’m wondering how this will be affected?

Thanks

#2

Your best bet is probably to just create those rotation images outside your program. Then just load the files during runtime. I just create 8 similar images, each pointing in a different direction.

Regards,
Igor

#3

[quote]Hello

I’m trying to make a 2D space game where each object is built up by an Image.

The problem is that I want the objects to be able to rotate. So I’ll need some way of rotating the object images.

I have understood that since Graphics2D.rotate() is really slow I’ll need to pregenerate the rotated version of the object image.
[/quote]
You can also pre-generate your rotated images within your app. Doing this makes your app more compact (we only need 1 sprite as compared to having dozens of pre-rotated sprites) and lets you easily adjust the rotation stepsize.

You can use AffineTransform ( ie, Graphics2D.rotate() ) to generate your rotations. But take care that your final rotated Image has a large enough size so that your sprite pic doesn’t get clipped.

Well, depending on the size and shape of your actual sprite pic, the bounding box of the sprite should change after each rotation.

For example, imagine a missile sprite positioned horizontally (ie, the tip of the missile facing east). The bounding box for such a sprite would ideally be the smallest rectangle (lying flat on it’s side) encompassing the sprite.

But when the missile is rotated 45 degrees counter-clockwise, facing northeast, how should the bounding box change? You basically have 2 choices:

  1. Recalculate the bounding box to be the smallest rectangle (lying flat on it’s side) encompassing the rotated sprite. This is known as an “axis-aligned” bounding box and can be represented by a Rectangle object. Collision detection using such a bounding box is very efficient and is easy to implement, but is not so accurate.

  2. Simply rotate the bounding box 45 degrees counter-clockwise as well, so that the bounding box is also facing northeast. This “object-aligned” bounding box can be represented by a Polygon object (since Rectangle objects must be aligned with each axis), and has the benefit of being more accurate and probably easier to implement, but not very efficient to compare collisions with.

#4
  1. If the aspect ratio of most of your images is 1:1, use bounding circles.
#5

Thanks for all for the great replys.

I got it “working” using this method:

public static Image rotate(Image source, int degrees) {
            
            int w = source.getWidth(null);
            int h = source.getHeight(null);
             
            GraphicsConfiguration gc = GraphicsEnvironment.
                   getLocalGraphicsEnvironment().getDefaultScreenDevice().
                   getDefaultConfiguration(); 
            
            Image img = gc.createCompatibleImage(w,h, Transparency.BITMASK); 
            Graphics2D g = (Graphics2D)img.getGraphics(); 
            g.translate(w/2,h/2); 
            g.rotate( Math.toRadians(degrees) ); 
            g.drawImage(source, -w/2, -h/2, w, h, null);
            
            return img;
      }

This only works with square images since otherwise the whole content wouldn’t fit in all angles.

I’ll have to figure out how to deal with the collision detection later on.

#6

This maybe of use to you :-

http://www.pkl.net/~rsc/4KShooter/4KShooter.jar

[or if you have a machine that doesn’t support accelerated full alpha :-
http://www.pkl.net/~rsc/4KShooter/4KShooterSE.jar]

sourcecode can be found :-

http://www.pkl.net/~rsc/4KShooter/A.java

p.s.

Be aware that it is not well structured code, as it is a 4k game. There are plenty of comments though =)
Also, it relies on fullscreen exclusive mode being vsync’ed (for timing).
If you have vsync disabled in your gfx card drivers, the game will be unplayably fast.