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.

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.

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

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.

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 )

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.

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?

Quote

* Things are getting better all the time...* Swing/2D are adding and accelerating newfeatures with every releaseHOWEVER* No matter how fast we go, you need to makesure you are making the best use of our APIs* Profile on your target environments

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

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

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.

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

if that is always going to be the case, then i believe Java has failed 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

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

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.

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.

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.

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

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.

Yep, what we need to shoot for is that whatever acceleration mechanisms are available on each platform are actually implemented. E.g. managed images for opaque or translucent images should be supported on the Mac. I suspect that they will be soon, it's just that the Apple folks were rushing to catch-up with their 1.4 release so naturally some things had to wait.

We know that Sun is working on acceleration via OpenGL on the Linux platform, so hopefully we will have a more even playing field soon.

A set of flags/properties that could be read to indicate what sort of acceleration is available might help a bit... but really for most games I suspect all it will lead to is a dialog that says your system isn't good enough to run this game ... even in a few years when the software methods would be fast enough anyway

Remember those games from Seirra that basically profiled the system in the installer so that they knew you could blit fast enough, and that your CD ROM would read fast enough etc..? Maybe we need something like that for Java?

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

You've got a good point. Unfortunately, given how controversial it could be, you have to be very careful how you phrase it (takes one to know one ...I've made I think about 5 posts on JGO which were perilously close to flame-bait because I didn't phrase them carefully enough )

To illustrate, when I first read your point:

Quote

Doesn't having to profile on every environment you intend deploying on defeat 1 of the major advantages of Java.Write Once, Run Anywhere

I instinctively disagreed. When I realised the full import of what you were saying, I agreed (flippant, aren't I? ). I've been here before, in the 1.0.x and 1.1.x days of java, when there were MANY more JVM's than there are now. In particular, I was trying to code to DOS and RISC-OS JVM's, which were ... um ... crap. The performance was so bad that e.g. something as innocent as new String() was a killer (String was much slower back then in general, so this is not a great example, but I can't remember the really nasty ones any more). I occasionally thank whatever deity that's to hand that most JVM's got dropped...it's better for a JVM not to exist, than to be so poor as to be unusable AND make it harder to write java code (because you, as developer, get the support headaches from people who's performance or bug problems are due to massively over-worked and under-performing JVM maintainer).

To para-phrase A C Clarke (badly): "Any sufficiently poorly-performing function is indistinguishable from it's non-implementation". (if the String constructor gets too slow, for instance, effectively there is no String class in Java since no-one can ever use it).

It is important to recognise the validity of this.

The WORA concept does not explicitly guarantee this within the word "run". It probably does imply it, though. Anyone who says "this is not guaranteed, and never will be" has a good point too - but this is largely because the word guarantee is too strong to be used with WORA, and shouldn't come into the equation: for hte most part, no-one ANYWHERE is in a position to guarantee any aspect of Java, not even Sun. You can fairly say that you can "never guarantee equivalent performance, even on one platform", but unless you pay them a very large amount, no one vendor would stick their neck out and "guarantee" any aspect of Java.

OTOH, if you talk about what WORA means in practice, then this performance aspect should always be considered part of "running successfully". Note that Java is expected not just to run, but to run properly, and to a minimum level of bug-less-ness (although that minimum level is not very high, cross-platform). It's fair to say it should also run at a minimum speed.

... but really for most games I suspect all it will lead to is a dialog that says your system isn't good enough to run this game ... even in a few years when the software methods would be fast enough anyway

Remember those games from Seirra that basically profiled the system in the installer so that they knew you could blit fast enough, and that your CD ROM would read fast enough etc..? Maybe we need something like that for Java?

It's an excellent, well-engineered, high-quality approach to application development. Sadly it won't get implemented on an individual-game basis in general, because capitalism doesn't like high-quality without solid financial justification. And if it's not being implemented by games devs, it's unlikely that anyone will make a generic version (and even less likelyh that devs will bother to use it, if they had so little need for it in the first place).

For most off-the-shelf games these days, 90% of the sales are made in the 3 months after release (sourced from various trade-press, can't remember which in particular - might even be the ELSPA surveys; probably slightly out of date). The only way they make more money is by releasing sequels or "deluxe"/"gold" editions. If you're going to re-release a gold edition (which only happens rarely in practice - it isn't effective for games which don't have a large hardcore contigent who would buy the same game twice just to get the version with the gold-foil on the box), you have to make some bugfixes anyway, and updating the "requirements check" is easy to do at the same time.

For subscription-based games you have to have online distribution / automated patching of some sort anyway, else you can't in practice charge a subscription. So, as soon as a sufficiently large number of players can't start the game but should be able to, you issue a patch that probably just disables all perf-checking entirely.

There is, of course, value to the dev studio's "brand" to have games that are still playable years later. My opinion of Bullfrog (and hence Lionhead) decreased considerably when I discovered I couldn't play Syndicate any more. I paid for the game, and I'd like to re-play one of their best games ever, but not a chance. Every time I want to but am rebuffed, their brand suffers. But they've got much bigger brand-affectors to worry about! I heard they aren't doing multi-player B&W2 because it's not justified in terms of expense / sales...if they're making decisions like that, how do you think they'd justify making their game "run well in 5-10 years time"?

You know, maybe a system profiler to determine a few scores for various aspects of Java gaming performance would be a good project for this group on java.net.

If we had a free standard library that could do some blitting tests with various image formats, check various things like fullscreen support, hardware acceleration, sound tests, IO, etc. Check for availability of various optional packages...

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.

yeah, this is a known bug. It'll give you a buffer strategy with accelerated buffers, but it'll be Blit strategy, not Flip.

I just thought I would point out that this app fails spectacularly on Mac OS X with Java 1.4.1... totally unusable. It's kind of hard to imagine how they managed to get it to behave so poorly. Could be Apple bugs.. but I've never seen anything else on the Mac do anything like this.

I just thought I would point out that this app fails spectacularly on Mac OS X with Java 1.4.1... totally unusable. It's kind of hard to imagine how they managed to get it to behave so poorly. Could be Apple bugs.. but I've never seen anything else on the Mac do anything like this.

[I'm the author of Mu...] I agree that it's mostly unusable on Mac OS X, which is pretty disappointing since that's my primary development platform (when I'm not at work). Fullscreen is especially broken with Apple's 1.4.1... I submitted 3 or 4 bugs to Apple that affect Mu, and I think they've been resolved for their next release. I also brought up the fullscreen issues to their 2D lead last time I saw him, and he's aware of them. He's hoping to have some of those resolved for the next release as well.

Thanks for checking out the app... Part of the goal of Mu is to demonstrate some "best practices" when using 2D, Swing, fullscreen, etc. all in conjunction. If you get a chance to try it on another platform, let me know how it goes, or if you have any suggestions/comments.

Fullscreen is especially broken with Apple's 1.4.1... I submitted 3 or 4 bugs to Apple that affect Mu, and I think they've been resolved for their next release. I also brought up the fullscreen issues to their 2D lead last time I saw him, and he's aware of them. He's hoping to have some of those resolved for the next release as well.

I am running the latest publicly available Developer Preview (DP102).. Are you running some later build that you know the issues have been fixed in? (would you be allowed to say if you were? )It's good news though, that many fullscreen issues will be fixed in the next release. I have high hopes that the Apple guys will get compatibility and performance of their JRE back on track with comparable windows and linux systems.

I am running the latest publicly available Developer Preview (DP102).. Are you running some later build that you know the issues have been fixed in? (would you be allowed to say if you were? )

I haven't tried the latest DP102 yet, but I'm pretty sure the fixes I mentioned haven't gone into that one. I'll keep my fingers crossed for the next one I guess (we don't usually get early access to Apple's DP builds).

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