Is this still considered "right"???

Java 2D
#1

Ok…some of my ideas of game development are a bit dated. :-[ I have only done game development at a hobby level, and the last time I put any significant time into it was in the Win32 days (prior to DirectX). I’m trying to get back into it and some of that involves un-learning what is no longer appropriate. So…

My project (as I’ve mentioned in a couple other threads) is a strategy game along the lines of Civ, Master of Orion & Heroes of Might & Magic (community building, resource management, etc). The core UI is a “command center” screen that gives you high-level info and lets you click off to other screens or pop-ups for details. I have considered using AWT for doing the interface, but I really don’t think that’s the most appropriate method.

In the “old days” many such games used a single bmp for all the static graphics on the UI. This had “cut outs” for buttons, resource counters, a main map, etc. You then had other images for those objects and when the user clicked on the screen you determined if the coordinates for that click were within the bounds of one of your buttons and executed the code for that. Additionally, you can add miscellaneous sprites for eye-candy (flashing lights, background movement, etc).

It would seem to me that this is still a valid implementation. No need to worry about chopping my main Frame into smaller containers. A single listener could handle all mouse events (from what I’ve tried so far). Drag-n-drop may be easier to implement (I haven’t tried this yet)…etc, etc. Now, as admitted I might be overlooking a great oportunity w/ AWT, or I may be causing myself unnecessary headaches going down this road.

Any feedback, opinions or experience is greatly appreciated.

-Lawrence ???

#2

AWT/Swing can be useful for dialogs and the like, but generally games want to have their own feel and style. In my opinion (being very careful not to offend anyone), the things you’ve said above are all still valid.

Kev

#3

I think Swing has a lot to offer.

If you are writing an action game, or a FPS, or something where you expect a lot of graphics changes pretty much every frame, then you probably don’t want to use Swing.

However, if you are writing a strategy game where most of the graphic content is static, or are things like buttons, then Swing will reduce your development effort by a huge amount, and will also reduce your bugginess.

Swing will let you develop your own look and feel – every component can be easily customized with borders, fill graphics, etc. So that argument is outdated (unless you want to make trapezoidal or hex buttons or something like that).

That said, Swing still has problems in fullscreen mode, so that might be a reason to not use it. I expect those will go away at some point.

For our current project we are using Swing for half of our interface, and Java3D for the other half. We are working on an MMO strategy game, so most of our Swing graphic content is relatively static (as compared to the 3D content).

#4

I kinda meant feel in terms of “tactile feel” as opposed to “Look & Feel ™”. All swing GUIs feel the same whether they look the same or not. At least in my view.

Kev

#5

I saw some very impressive Swing demos at JavaOne, including one that I would never have believed was Swing because the feel was very different – a picture chooser that had a semi-circular scrolling “thumbwheel”, and a fish-bowl style image viewer, all on a translucent background with animated gradients flowing through it.

There were no “buttons” anywhere, or even any of the normal Swing widgets. Except everything was actually fairly straight-forward Swing components, with some tweaking of backgrounds, transparency, gradients, etc.

IIRC, the speaker said it took them about a day or two to create it.

#6

Coo, I thought I knew quite a bit about swing, but I wouldn’t have the foggiest how to get some of those effects…

I doth stand (sit) corrected.

Is there anywhere we (humble, poor) people can see the demos?

Kev

#7

Yeah I would definately like to glance at such cool sounding Swing UI’s.

#8

First, thanks for the input so far!!! :slight_smile:

That ‘feel and style’ issue is the biggie that I’m worried about. I know I can replace generic buttons with a graphic and such, but I don’t know if it’s really flexible enough. I am a firm believer that for what I’m working on I do not want any part of the UI to look like a “normal” Windows/XWindows/MacOS interface. If the game is based in a fantasy situation for example, there should be nothing on your screen that distracts from the suspension-of-disbelief. A generic looking frame, menu, etc does that.

Example: One key limitation I have heard about with AWT / Swing is the shape and placement of some components. In a fantasy-set game for example, I may want to have my “buttons” be various colored crystals (w/ basic animation to create a feel of depth, sparkel and “magic”). Some would be oval, round, square or hex shapped. They’re not the same size and I may not want them lined up perfectly. Additionally, I don’t want a bounding-box situation where you can click “outside” of a crystal, yet still within an imaginary rectangle drawn around it, and have that count as a click.

Could something like this be done w/ just extending AWT and/or Swing components?? I know it could be done by creating a background image for the crystals to sit on, then creating some basic sprite animation for the cyrstals themselves, and just rendering it. I then map all mouse clicks and determine what objects to call based on what crystal’s image was clicked. It’s more work than just extending a button, but… ??? If it matters, I am doing my game in an undecorated AWT frame modeled after this: http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=share;action=display;num=1036791657 )

As always, advTHANKSance!!!
-Lawrence

#9

Dang it!!! I got distracted by work and by the time I actually hit “post”, there’s already a full discussion going on about what I’m writting. :frowning:

I would DEFINETLY be interrested in seeing such examples, especially if we can see HOW they did it as well!!!

-Lawrence

#10

In theory, you could create your own custom components to handle weird shapes, sizes, placements, etc, which you could use for your “crystal buttons”. I haven’t done this myself in Swing, but there’s probably someone here in the forums who has.

As for seeing the JavaOne demos, you can click here to get the Java Desktop slides, if you are a JDC member.

The name of the presentation with the cool demo is: Get Rich Quick: Taking Advantage of Java 2DTM API in Your Rich Client Application (PDF form)

Unfortunately, the Demo itself is not there, just some examples of how to do scaling, gradients, animation, etc… :frowning:

#11

Yes you can do all that with Swing…

Use a null layout manager.

Set components to be NOT opaque so that the background shows through when they don’t fill their bounding box.

See the Java Tech Tip for Round Buttons to get an idea how to make the hit tests only work within the bounds of the actual graphic, not the bounding box.
http://developer.java.sun.com/developer/TechTips/1999/tt0826.html#tip1

Check the Java2D demos.

#12

Check out this JavaOne presentation slides:
http://servlet.java.sun.com/javaone/sf2003/conf/sessions/display-1493.en.jsp

The demos mentioned above were written for this presentation.

#13

eek!

I assumed getting a GraphicsConfiguration that is specific to the Device you intend to be rendering onto is the right way of doing it.
Yet, the slides tell you to forgo the right way, and use the lazy way cos its quicker :S

What would happen if you have multiple different GraphicsDevices?
By my understanding, wouldn’t using getDefaultConfiguration cause all sorts of bugs?

The last statement here is abit disturbing as well :o
Doesn’t having to profile on every environment you intend deploying on defeat 1 of the major advantages of Java.
Write Once, Run Anywhere ???

#14

It’ll still run on the various platforms, but it may not run fast. The profiling recommendation is for when you need to get optimum performance on all of your target platforms.

This is something that’ll likely never go away, because each platform will have it’s own weird quirks based on both the hardware and software. Java really just guarantees that any 100% compliant JVM will run bytecodes that were created by a 100% compliant Java compiler.

#15

Right. Java can’t equalize the performance of dissimilar platforms if the OS imposes certain restrictions and delays. Different platforms will always have different performance characteristics. Java or anything like it will never change that.

It IS mostly “write once, run anywhere” but you must test. “Write once, test everywhere, tweak stuff, run anywhere” is closer to the actual development cycle :slight_smile:

#16

if that is always going to be the case, then i believe Java has failed :frowning:
IMO comparable performance on comparable hardware should be a requirement of any JVM.

The current OSX JDK is a good example of this.

mid-range Windows machine in a standard desktop resolution - several thousand image blits/second @30fps.
mid-range Mac in a standard desktop resolution - can you even get 30fps with 0 blits/second???

If its going to run at that kind of speed.
It might as well not run at all ::slight_smile:

I know that particular example is a short-term issue that will probably[it bloody better!] be fixed by the next JDK release.

However, the problem remains.

You write a game that makes use of image rotations [through AffineTransform] with the expectation that they will be accelerated. (once they eventually become accelerated…)
Some1 runs your code on a machine that doesn’t support hardware image rotation.
The game will be unacceptably slow.
What do you do?
rewrite your game so it pre-caches every single rotation? in a game of any scale, this will be totally impractical.

You end up having to say, sorry it won’t run on your machine configuration.
Ofcourse you can still say ‘Write once, run anywhere’, but as in any realtime system, a late answer is a wrong answer :stuck_out_tongue:

#17

No, Java hasn’t failed. Java never made any promises about relative performance on each JRE implementation. Because it simply is not possible.

Even in C/C++,assembler,etc… it is NOT possible. Even on the exact same hardware. Different operating systems will have different constraints. Mac OS X displays are always double buffered for instance. On Mac OS certain pixel formats will blit faster than others because of how they fit into the display architecture and the use of OpenGL for the native Mac UI. No programming language or runtime environment is going to change that.

Same with your hardware acceleration example for AffineTransform… what do you expect? I see this as not much different than the standard “System Requirements” that you see on the bottom panel of any packaged software. Remember when 3D games came with software only engines that required a certain CPU speed… OR they would print on the box, requires a 3D accelerator (with a slower CPU)? The only problem is that the cross-platform nature of Java exposes more variables like those. It’s not like this is something new.

I agree that it makes things difficult sometimes for developers, but tough, that’s simply the way it works.

#18

[quote] You write a game that makes use of image rotations [through AffineTransform] with the expectation that they will be accelerated. (once they eventually become accelerated…)
Some1 runs your code on a machine that doesn’t support hardware image rotation.
The game will be unacceptably slow.
[/quote]
How’s that different from a game developed in C++ with DirectX/3D/OGL? If your hardware doesn’t support features required by the game, it’ll run through sw loops and will be slow. OpenGL failed, then.

I understand that this is not a 100% correct comparison, but you get the point.

#19

I’ve managed to forget to post a link to this great app which was used in that presentation:
https://mu.dev.java.net/

The source code is available, and the app webstartified:
http://mu.dev.java.net/latest/mu-rich.jnlp

#20

ok, maybe I was a little harsh blaming Java for problems that are realy caused by the evilness that is abstration :wink:

Java still needs a way of getting hardware Capabilities though.

For instance, if your platform supports hardware images, but doesn’t support hardware alpha compositing.
Making use of much alpha compositing at all, is going to be so detremental to speed, that it would be much better to forget hardware acceleration altogether, and keep your images in main memory.

Is getCaps() (or something similar) going to feature in 1.5?

Incidentally, BufferStrategy always gives you a hardware accelerated backbuffer if its available, even when you request a software backbuffer.
Which makes encapsulating a pain, cos you have to create a regular BufferedImage and do the back buffering yourself if you don’t want acceleration.

 frame.createBufferStrategy(2, new BufferCapabilities(new ImageCapabilities(false),
                                                                   new ImageCapabilities(false),
                                                                   null));