zooming in a 2D rts game in java

[masternerdguy]

I am writing a 2D java RTS where every pixel represents a kilometer. It is a space game.

Everything is to that scale (realistic planets!), but I have a problem: I can't figure out how to make a minimap for it.

Since the minimap would be pathetically innacurate (even filling the 1024x768 screen it would still need every pixel to represent over 90,000KM!) I have decided to use the middle wheel of the mouse to make it zoomable.

Then a user can zoom out from 0 zoom (normal scale) to -12 AU zoom (the entire map fits on a 1024x768 screen) in 1 AU increments.

So, to make this happen....

1. How do you scale images in Java2D?
2. How can I change the distance between 2 objects on the screen without compromising their real distance from each other?

I thought of simply scaling the distances and image sizes down, but then realised that would bring units and planets closer together and my game engine would think they were right next to each other.

Complex problem, need help.
Thanks in advance.

[Fubarable]

I've got a bad feeling about this problem. Your model and your GUI absolutely need to be separate. In other words your game engine shouldn't know, nor should it care how you are displaying the GUI (for example, the scale you are using), else your design is broken.

What I think you should do is have your model hold the absolute position of your game, and then have your GUI display the model with whatever scale it chooses. Thus the main GUI will show the game at one scale while the small map will show the same model data but at a different scale. Again, these displays should have no effect on the model itself.

[JosAH]

Every Graphics object you use actually is a Graphics2D object (you have to cast to it). A Graphics2D object has an AffineTransform object attached to it. Read about it and see how scaling (among other operations) work.

kind regards,

Jos

[masternerdguy]

I've got a bad feeling about this problem. Your model and your GUI absolutely need to be separate. In other words your game engine shouldn't know, nor should it care how you are displaying the GUI (for example, the scale you are using), else your design is broken.

What I think you should do is have your model hold the absolute position of your game, and then have your GUI display the model with whatever scale it chooses. Thus the main GUI will show the game at one scale while the small map will show the same model data but at a different scale. Again, these displays should have no effect on the model itself.

a way I could do this would be to have an absoluteX and absoluteY (for example) and then a scale factor that the GUI is derived from.

So the game engine won't know the objects are scaled but my GUI component (called HUD.java btw) will.

Think that can work?

[masternerdguy]

I solved the problem.

What I did was I had a variable called zoomFactor that is a double. By default it is 1, so no scaling. When zoomFactor is changed, it scales the images to their new size by multiplying zoomFactor by their .getWidth()s and .getHeights().

For repositioning, my GUI components (I have 3 affected classes, Planet.java, Structure.java, and Asteroid.java. Each class does its own drawing) multiplies their positionX and positionY by zoomFactor to determine the scaled position.

Finally, rectangles used for collision testing are scaled by multiplying their x and y by zoomFactor and their width and height by zoomFactor.

But when you zoom out so much zoomFactor == 0.01 (which is not that far, not even 0.25AU) you have a problem where the images scale to a size smaller than 0, throwing an exception.

So, if either the X or Y sizes are smaller than 0, the final image size is set to 1x1. Eventually an icon will be drawn over their location.

[Supamagier]

You could do the following:
On the minimap, you simply use colors instead of images, in the first place. A minimap is small, so that shouldn't be a problem.

Than you adapt your game engine so that every object will be tracked so that you know what the absolute position is of the object. (Don't work per pixel, divide the screen in, for example, 100x100 squares. But not more than the size of your minimap

Than, when drawing your minimap, you simply calculate where you should draw every pixel, and in what color.

Using this, you could get a fairly accurate minimap. The only problem is that when multiple objects are in the same area, you either calculate where in that tiny area of your minimap to draw which object, or you just show one object; the most important one.

Another solution could be (in combination with the one above): show a smaller part on your minimap than you do now. :)

~Matt

[masternerdguy]

You could do the following:
On the minimap, you simply use colors instead of images, in the first place. A minimap is small, so that shouldn't be a problem.

Than you adapt your game engine so that every object will be tracked so that you know what the absolute position is of the object. (Don't work per pixel, divide the screen in, for example, 100x100 squares. But not more than the size of your minimap

Than, when drawing your minimap, you simply calculate where you should draw every pixel, and in what color.

Using this, you could get a fairly accurate minimap. The only problem is that when multiple objects are in the same area, you either calculate where in that tiny area of your minimap to draw which object, or you just show one object; the most important one.

Another solution could be (in combination with the one above): show a smaller part on your minimap than you do now. :)

~Matt

I had tried that idea. I realised my maps would always be 12AU by 12AU, so I made a grid out of it. You would select the grid and then you could select subgrids and then more subgrids......

The problem was it was terribly inneficient. What if you were only looking for a frigate (less than 1km across) in an area of space 1,800,000,000KM by 1.8b KM?!

Zooming + icons, although slower than in a 3D game since in 2D you have no LOD, lets you take in vast chunks of space at the same time and navigate easily.

[Supamagier]

You should change the dot size than. And give each object an absolute x and y. I don't see how that is terrible inefficient. But than again, I might be a bit shortsightened in this case.

[JosAH]

Did anyone read my reply #3?

kind regards,

Jos

[masternerdguy]

Did anyone read my reply #3?

kind regards,

Jos

yes, Affinetransform is how my game achieves scaling.