Is this still considered "right"???

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 :smiley:

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?

[quote]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.
[/quote]
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 :wink: …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:

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.

[quote]… 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 :smiley:

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?
[/quote]
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…

That might be useful.

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

[quote]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
[/quote]
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.

Thanks,
Chris

Is it a known bug that is going to be fixed? :wink:

[quote]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.
[/quote]
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? :slight_smile: )
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 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).

Chris