I have looked at the Online Casino/Gaming downloadable games, and most seem to be have written in C++ / MFC. Is this because of:- Download speed: Is this because of the smaller size of application for downloading (about 5 MB), compared to 20+ MB for a similar Java application. - Speed of execution: I know that Java is certainly catching up in terms of speed.

- experience I would guess also, there arn't that many professional java game developers out there (outside of the mobile market)- cause everyone does it that way, new one tends to aswell - lack of risk takers.- lack of visibility, some people still not aware that Java can do anything else other than those cute little applet things

They were probably written in C++/MFC because that's what the developers were used to (and therefore would be more productive with it). If you're familiar with both platforms I would say Java is easier and also has better tools.

I have looked at the Online Casino/Gaming downloadable games, and most seem to be have written in C++ / MFC. Is this because of:

Nothing at all to do with either of those

Quote

Anything else?

Having spoken to a lot of the developers ... the primary reason, sad though it is is:

"Because Flash turned out to be too damn crap to do the job properly ... and by writing it in C++ we were able to avoid all the problems of Flash"

(or Shockwave, etc)

Really. These games tend to be written on such short timescales that there isn't much need to worry hugely about what language you're going to use, and so C++ has ended up being used as much as anything because it was "good enough to get the job done". Over time, you might well see more games move towards C# (if MS can get the massive .NET installed on enough PC's) or java (if Sun can get java installed on enough PC's and fix the webstart bugs that make it unusable for most commercial companies), because it saves dev time - but the major cost with casual and web games isn't dev time or code quality, it's game-polishing and marketing, so it's just not where people are concentrating their effort right now.

But tell me how complicated it is to do an open-source replacement of WebStart ? Does it require some tricks only available to the big bad sun ?

I believe those already exist, I've seen at least one on sourcefourge. However the main draw with webstart is that it's pre-installed. If you're going to get the user to download and install a custom webstart then why not skip the middleman and just download and install the app directly?

But tell me how complicated it is to do an open-source replacement of WebStart ? Does it require some tricks only available to the big bad sun ?

I believe those already exist, I've seen at least one on sourcefourge. However the main draw with webstart is that it's pre-installed. If you're going to get the user to download and install a custom webstart then why not skip the middleman and just download and install the app directly?

I agree with you. I never understood all the noise that was made about Java Web Start.. You can simply do the following :- You deploy from a web site, from which you detect the platform (like on the Mozilla site) and suggest the right download, YET permitting to download another version if needed- The user then have a nice .zip file which he then unpack and find : - An .exe file (Win) OR - An executable file (*nix) - Something else (Mac ^^)- Then playing is a (double-)click away !The major issue with that is that the user really don't know where to unpack its zip file.. in Program Files ? no it's not a program, it's "java" However this style of distribution is really simple and efficient. Tiltilation is distributed this way on Linux and it "just works".Otherwise, an installer (IzPack, Install4j) is perfectly viable, too.

The thing that Web Start gives you is a system that will auto update and auto select the appropriate version of Java. Though I've rarely seen issues with running things on the latest Java release, sometimes you just want the security of running on the same version that you've tested on.

Java Web Start is only good for very simply things though... It's not quite what client-side developers want it to be in my opinion. It's more like an applet cache that can do applications too.

But you are right when you say a simple ZIP file will do the trick in most cases. Just pack everything neatly in a folder so that the application remains somewhat self-contained when unzipped. You can always put some logic into your code to check JRE versions and stuff if you need to. Or you can zip up a JRE with the app - which sort of sucks and is the main reason that Web Start could be better.. if only developers had more control of the application install.

The main benefit of java webstart for games developers is the callback to get updates - for online games designers this is has got to be a boon. I think thats pretty useful - though writing your own updater (or using one posted in Shared Code) isn't really that tricky.

If you're obsessed with using the latest and greatest VM then the ability of java webstart to get the user the next VM is useful - but they of course had to get through the initial java download/install in the first place.

JNLP as a tech is pretty nice - Webstart as an implementation is the problem.

IMHO the best thing about webstart is that apps start to behave closer to a native app - just a single click to launch, no messing around with zip files (which most users don't know what to do with), no messing with installers (that work, but are an extra few clicks) and no getting the user to run a .jar (which may have had it's extension pinched by winzip or winrar anyway).

However as Kev said the current implementation is pretty bad. Theres a whole load of bugs, and users just don't know where to find the app when they run it again (app / applet cache is a pretty good summary of the current state of play).

I'm toying with the idea of a webstart 'installer' - a webstart app which does little more than prompt the user for an install dir and copy the app into it. You still need a JRE + webstart, but it makes the whole thing a little closer to a native app (probably with a .exe stub for windows users too). You'd loose the auto update for the app itself, but you could always use an existing 3rd party lib for that.

In 3d games it's all about raw speed. Same for realtime simulation-software.

For GUI and (not too busy) webservers, a difference of factor 2 would hardly be noticed.

That doesn't mean performance is a trivial argument, because Java is used on busy webservers and is now also more and more being used in realtime simulation and 3d games (ok, a few).

Still native SSE beats the the crap out of array/vector-math inside the JVM with over 30-50% faster execution. (>400% for sqrt) We desperately need some native math library that's not attached to some other (commercial) project.

The latest hardware seems to make everything 'fast enough' to be interactive, but in the 3d-game-world, it's about getting all possible performance out of the hardware, which is never 'fast enough'. I remember in some wicked Sony interview about performance on the PS3 where an artist said: "in the old days, we had to put a lot of effort in optimizing the engine, with the hardware of the PS3, we can do everything without worrying about performance!" - don't you just love those idiotic marketing talk?

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

[...]I remember in some wicked Sony interview about performance on the PS3 where an artist said: "in the old days, we had to put a lot of effort in optimizing the engine, with the hardware of the PS3, we can do everything without worrying about performance!" - don't you just love those idiotic marketing talk?

Haha. Well, that time will come. One day you'll be able to simulate a complex world, photorealistic graphics... and all that written in interpreted basic. Then you really dont need to worry about performance anymore.

Regarding java and the present... I dont worry about java's performance anymore. I can do the stuff I always wanted on 6 year old hardware and that with a fraction of the coding time.

The problem is, I can't get it to compile because my C-compiler borks at the instrincs, but Darkprophet got it to work with his compiler, and walked away with it for Volatile-Engine.

Errr, that never happened. And if my memory serves me right, you were a developer for a short time on VE too. And second of all, I didn't *just* compile the thing...i wrote it with you. The only reason we didn't release that is because we had a personality clash...

I still have the code lying around if you would like to continue the project peacefully

In 3d games it's all about raw speed. Same for realtime simulation-software.

For GUI and (not too busy) webservers, a difference of factor 2 would hardly be noticed.

IMHO, that's not true at all. A factor of 2 performance is ALWAYS noticed. For instance, if the webserver runs twice as fast, you can use much cheaper hardware (hosting companies always have "old" servers lieing around not being used that they'll rent to you cheaper).

Quote

I remember in some wicked Sony interview about performance on the PS3 where an artist said: "in the old days, we had to put a lot of effort in optimizing the engine, with the hardware of the PS3, we can do everything without worrying about performance!" - don't you just love those idiotic marketing talk?

Just going by the publicly available info on the PS3, that's blatantly not true .

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