Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (494)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  zoomable tile based map  (Read 4919 times)
0 Members and 1 Guest are viewing this topic.
Offline Thyast

Senior Newbie




I'm not superstitious, it brings bad luck.


« Posted 2003-10-09 11:25:05 »

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 Smiley -

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



Offline Herkules

Senior Member




Friendly fire isn't friendly!


« Reply #1 - Posted 2003-10-09 12:02:27 »

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

HARDCODE    --     DRTS/FlyingGuns/JPilot/JXInput  --    skype me: joerg.plewe
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #2 - Posted 2003-10-09 12:08:44 »

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!  Smiley
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!
Legends of Yore - The Casual Retro Roguelike
Offline Thyast

Senior Newbie




I'm not superstitious, it brings bad luck.


« Reply #3 - Posted 2003-10-09 13:07:12 »

@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.
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #4 - Posted 2003-10-09 13:12:39 »

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 Smiley ).

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline kevglass

JGO Kernel


Medals: 163
Projects: 23
Exp: 18 years


Coder, Trainee Pixel Artist, Game Reviewer


« Reply #5 - Posted 2003-10-09 13:19:30 »

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

Offline Thyast

Senior Newbie




I'm not superstitious, it brings bad luck.


« Reply #6 - Posted 2003-10-09 13:31:19 »

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 ?

Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #7 - Posted 2003-10-09 15:21:58 »

Quote
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 Smiley 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.

Quote
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!).

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline dsellars

Junior Member




Need to write more games


« Reply #8 - Posted 2003-10-10 07:21:56 »

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.  
Offline Thyast

Senior Newbie




I'm not superstitious, it brings bad luck.


« Reply #9 - Posted 2003-10-10 10:09:48 »

Argh ! too much APIs to choose from  Wink
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!
Legends of Yore - The Casual Retro Roguelike
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #10 - Posted 2003-10-10 11:21:18 »

Quote
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

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Offline Thyast

Senior Newbie




I'm not superstitious, it brings bad luck.


« Reply #11 - Posted 2003-10-10 16:58:03 »

thanks a lot
Offline Thyast

Senior Newbie




I'm not superstitious, it brings bad luck.


« Reply #12 - Posted 2003-10-16 10:14:23 »

It's me again  Grin

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 ?  Roll Eyes ).

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
Offline sma

Junior Member





« Reply #13 - Posted 2003-11-05 07:07:42 »

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 Sad

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!).


.: Truth Until Paradox!
Offline Thyast

Senior Newbie




I'm not superstitious, it brings bad luck.


« Reply #14 - Posted 2003-11-05 12:59:04 »

Quote
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.

Quote

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 Sad


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.

Quote

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.  Wink
Offline Thyast

Senior Newbie




I'm not superstitious, it brings bad luck.


« Reply #15 - Posted 2003-11-10 13:37:43 »

Quote


[...]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 ! Grin
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Dwinin (19 views)
2014-09-12 09:08:26

Norakomi (54 views)
2014-09-10 13:57:51

TehJavaDev (63 views)
2014-09-10 06:39:09

Tekkerue (31 views)
2014-09-09 02:24:56

mitcheeb (53 views)
2014-09-08 06:06:29

BurntPizza (37 views)
2014-09-07 01:13:42

Longarmx (23 views)
2014-09-07 01:12:14

Longarmx (27 views)
2014-09-07 01:11:22

Longarmx (27 views)
2014-09-07 01:10:19

mitcheeb (35 views)
2014-09-04 23:08:59
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!