zoomable tile based map

[Thyast]

Hello,

I couldn't find info on this topic so if someone here has experience about this, it would be great.

I'm trying to do a scrollable, *ZOOMABLE* top-down tile based game. Zooming should be smooth and done with a slider, as it was done in Interplay's MAX for instance. - If you don't know this late 90's game, so you missed something -

My concern is obviously with perf problems. I can think of two ways of doing it.

I assume tiles are 40 pixels in side.

1° I will have to draw and maintain a 1:1 scaled image  and then scale and copy the part that is visible to the canvas. What it takes :
* memory for the 1:1 picture (let's say at max zoom out it would allow displaying 160x160 5 pix tiles map on a 800x800 canvas which makes an offsceen 1:1 pic of 6400x6400 32bits = about 16.4 MB)
* memory for the unitary ground textures and units (1:1 scale)
* a scale operation of the 1:1 pic each time the visible part of the map changes (unit movement, scrolling, zooming in/out) and a copy of the complete result to the canvas.
possible optimization : only scale and copy the part that has changed (for scrolling and unit movements only; not possible when scale factor changes - but i fear artifacts at the borders of the updated zone).

2° Maintain an offscreen buffer sized as the canvas and paint already scaled ground textures and units on it.
What it takes :
* memory for offscreen buffer (less than for the 1:1 pic however)
* memory for the unitary ground textures and units (1:1 scale)
* memory for the scaled textures and units
* a scale operation on the textures and units when zooming in/out and a complete redraw of the offscreen buf (only required for the visible ones).
* a 1:1 copy to the canvas of the part of offscreen buf that has changed.

I'd like a rather smooth graphical result when scaling. And I have the intuition that picture would be better with a global scaling as in 1° than with a assembly of "unitary" scalings as in 2°.

I can't rely on pre-scaled pics as scale level should also be smooth. I could probably have 2 or 3 textures scaled for each unit as an optimization but not more.

So do you have any advice on this or maybe a third option ?

thanks for your help

[Herkules]

http://www.cs.umd.edu/hcil/jazz/

[erikd]

My third option would be to let the hardware handle the scaling and don't worry too much about performance just yet.
Try not to make things too difficult in an early stage in order to prevent bad performance. Remember that premature optimization is the root of all evil (even though I have to admit it's not always a bad idea to consider performance beforehand).
Just write it simple and clean and then fix performance if necessary.

Using Java2D on windows actually gives pretty good scaling performance, especially when you enable the runtime flags for accelleration.
I did a game a while ago which heavily depended on scaling bitmaps on the fly and performance was not at all a problem (at least not on windows). On some machine that didn't sync to the monitor, performance was even too great!  
For good performance on other platforms like linux, you'll have to wait for java 1.5 though (I think j2d will use opengl for accelleration).

You might also consider using an openGL wrapper.

Games published by our own members! Check 'em out!

[Thyast]

@Erik :

Well with what I'm doing, hardware will already handle scaling since I'm using SWT. SWT's GC image copy method call an OS function which does scaling if necessary.

So I will do it simple and have a look at the result. Then think about it again if it doesn't look good.

Tanks for your help.

@Herkules : i'll have a look at it. Thanks also.

[Orangy Tang]

You'll save yourself a while bunch of problems if you use OpenGL - you won't have to worry about image caches and the like, and you can let the hardware perform all the work. But mainly the big win is the quality - doing image scaling without some sort of filter gives you that annoying 'shimmering' effect (even a simple bilinear filter works wonders to practically eliminate this temporal aliasing, add mipmaps and its totally gone ).

[kevglass]

OpenGL does have the downside of being increadible slow on machines without a real driver, where as Java2D keeps you in the accerelated world (albeit a limited slower accelerated world). This is part of what J2DA was trying to address.

Kev

[Thyast]

Concerning OpenGL, I'm only planning to do a 2D game so I did not want to use it. I may do it later but I think for now it would be to much for me to learn. And integration with SWT could cause trouble.

Concerning quality, it seems SWT does not offer filters (yet ?). Do you think that since SWT relies on hardware for scaling, some kind of filtering is done by default ?
If not, would it be possible to do it after the scaling is done ? I think that bilinear filtering is simply a way of calculating scaled pixels from the value of  the group of original pixels that make it, isn't it ?

[Orangy Tang]

Concerning OpenGL, I'm only planning to do a 2D game so I did not want to use it. And integration with SWT could cause trouble.

It does work equally well with 2d or 3d, It's making my 2D game look much nicer I did hear that there was a GL canvas in SWT somewhere, so intergration could be easier than you think. Not tried it myself though.

Concerning quality, it seems SWT does not offer filters (yet ?). Do you think that since SWT relies on hardware for scaling, some kind of filtering is done by default ?
If not, would it be possible to do it after the scaling is done ?

Hell no. Theres no standard interface for 2d filtering thats avalible in hardware, except for those provided by the 3d APIs. You could do a fullscreen AA by reading back the framebuffer and filtering it down to half size, but then you've got to either read back over the AGP bus (slow!) or do all the blitting yourself (even slower!).

[dsellars]

I'm doing something similar at the moment 2D top down (I'm using J2DA).  I havn't got the scaling working correctly as I don't get much time.  If I do I'll post it.

I would look into using anOpenGL wrapper though as the results are much better.  If you use Kev and Troggan's J2DA all the detail is hidden away so you don't need to spend ages leaning into GL.

good luck,

Dan.  

[Thyast]

Argh ! too much APIs to choose from  
But I will have to, since it seems to be the only way to reach the quality level I want.

So I looked at all this :

* J2DA : It doesn't seem to work with SWT so I would have to abandon it for AWT/Swing which I do not want to do.
* openGL : I can use the official OpenGL plugin for Eclipse/SWT and maybe JOGL but I am not sure that JOGL SWT interface is finished since I did not find clear info about this (However rob grzywinski said it would be finished by the end of june, so maybe...) But I will have to learn using OpenGL which could take much time since I haven't got a clue. Could someone just give me some hints about how to do want I want to ? I mean : what kind of functionnality should I look first in the docs and tutorials ?
* piccolo : it seems to do what I need but I'm still reading the doc. And I have to experiment for perf.

Games published by our own members! Check 'em out!

[Orangy Tang]

Could someone just give me some hints about how to do want I want to ? I mean : what kind of functionnality should I look first in the docs and tutorials ?

You'll need an orthographic projection (no perspective) via glOrtho, then render your sprites as textured quads. You can ignore most of the functionality other than that to start with, although you'll probably want to look into the blending modes as well at some point.

See:
http://nehe.gamedev.net/
http://www.gamedev.net/download/redbook.pdf
http://msdn.microsoft.com/library/en-us/opengl/apxb4_82lh.asp

[Thyast]

thanks a lot

[Thyast]

It's me again  

Just to let you know (if it can be of use) that I've been experimenting with Piccolo zooming API and that it doesn't filter anything with SWT support. In fact Piccolo is a kind of high level wrapper that relies on sub level APIs' scaling functions to do it's job. And as SWT doesn't filter, Piccolo won't either.

So I'm wondering if SWT is a good choice. I wanted to work with SWT as it's quicker than Swing and nicer than AWT. And I don't want to spend time on building my own GUI yet. The remaining solutions if I want to keep working with SWT and have a nice result is using a GL wrapper or a Java2D bridge. Another problem with SWT is that it doesn't support customizing mouse wheel events ! (Can you believe it ?   ).

For now I'm considering experimenting J2DA as it seems
to integrate basic controls that I need.
@Dan : If I succed, I'll post the code.

Thyast

[sma]

It's interesting that you considered using SWT for a game. I'm doing the same for a very simple strategy game right now but I'm not sure whether I could live without antialiased graphics (doing all graphics in Java2D and blitting the result into an SWT canvas would work but nullifies one advantage of SWT - no dependency on AWT)

You're right about the mouse wheel issue - I recommend to file a bug if you need this feature. Generally, the Eclipse team is very helpful. At least on Windows, it shouldn't be a problem to receive and fire mouse wheel events. You'd have to overwrite WM_MOUSEWHEEL() in a subclass of Canvas in the same package because of visibility restrictions - that is you'd have to kind-of-modify SWT

Regarding scaling images: At least on Windows, SWT uses StretchBlt with COLORONCOLOR mode.  You might get better results with the HALFTONE mode - I never tried this and this would again require hacking SWT (but it's open source, you can do this!).

[Thyast]

It's interesting that you considered using SWT for a game. I'm doing the same for a very simple strategy game right now but I'm not sure whether I could live without antialiased graphics (doing all graphics in Java2D and blitting the result into an SWT canvas would work but nullifies one advantage of SWT - no dependency on AWT)

Graphics quality is obviously of importance to me. That's why I experimented J2DA then chose to use OpenGL directly since J2DA does not allow zooming easily (yet?). As I still was interrested in SWT for the native widgets it offers I used the OpenGL wrapper plugin for SWT and I had some good nice looking results with zooming. It was not as hard as I had thought to learn the parts of OpenGL I needed for this with the help of the links given by Orangy Tang. But I stumbled on a bug again, in the openGL plugin this time : it does not handle RGBA transparency as it should. It's a bug in the image conversion method of the GL GC class. It was 2 weeks ago and I did not have time to work on it again. Maybe if someone here wants to help with it, we could at last have an efficient way of mixing OpenGL with a quick good looking windowed GUI. I looked for another solution of making good graphics with nice looking and quick widgets (at least these : multicolumns list, checkbox, combo, radiobuttons and slider) but I could not find any.
For the GL bug fix I'm almost sure we won't have support from the eclipse team since this plugin is experimental. Although I haven't tried yet.

You're right about the mouse wheel issue - I recommend to file a bug if you need this feature. Generally, the Eclipse team is very helpful. At least on Windows, it shouldn't be a problem to receive and fire mouse wheel events. You'd have to overwrite WM_MOUSEWHEEL() in a subclass of Canvas in the same package because of visibility restrictions - that is you'd have to kind-of-modify SWT

I voted for the bug fix already. Maybe it will be fixed in next version with a little bit of luck. But there wasn't many votes so it's doubtfull. I will have to do it myself the way you say eventually. But I can live without for now.

Regarding scaling images: At least on Windows, SWT uses StretchBlt with COLORONCOLOR mode.  You might get better results with the HALFTONE mode - I never tried this and this would again require hacking SWT (but it's open source, you can do this!).

As I now use OpenGL, I'm not using SWT scaling anymore. But thanks for the tip.  

[Thyast]

[...]I stumbled on a bug again, in the openGL plugin this time : it does not handle RGBA transparency as it should. It's a bug in the image conversion method of the GL GC class.

Ok. I managed to fix the bug today : I just don't use the picture conversion routine from the GL wrapper plugin and made my own instead. Anyway that routine was 100% java/SWT so I'm not loosing in efficiency. Here is some tips to know about it :
* texture dims must be a power of 2 (2,4,8,16,32,64,128...),
* SWT ImageData (and probably all plateform independant API as said in GL doc) have BGR format by default (GL_BGR_EXT or GL_BGRA_EXT types for openGL)
* 8bits gif pics with transparency must be converted to RGBA format using palette and ImageData.transparentPixel property. Be carefull ImageData.data (pixel values / byte array) size can be bigger than the number of pixels of the image (a multiple of 100 probably).

Let me know if you need example source code.

So now I have a good looking and quick GUI with a powerfull way of drawing. Cool !