Quake 3 still has many active servers... Lets assume that we have a server with 16 people connected. You are not going to get away with you tube quality here. But lets assume there is some serious codec magic going on and you can get 1 frame latency with 10Mbit (I seriously doubt 720p60 at 40Mbit would good enough). Lets assume a 50% occupancy and we have 12*16*3600*10Mbit => 864 Gbyte *per day* *per server* (only 16 players!) or 26Tbytes per month for *one* server. Compared to quake live which has a usage of about 5Mbyte per hour for 16 people on a server (ie 60Mbyte for 12 hours). Even if the encoding could get the bit rate down to 1Mbit its still massive compared to a normal system. So quake live will be cheaper... and we haven't even started talking about the hardware required to render and encode this data, the cooling or the rent. And lets not forget a pipe thats 1000x larger than your competitor is going to cost more too.

YouTube is streaming video constantly, all day every day. It's not what I would say is good quality, but tonnes of people find it acceptable and the quality is improving. YouTube is also expected to make a profit this year.

Maybe a subscription fee isn't enough, maybe there will need to be more advertising in games as well to help pay for the service. But YouTube is real life example proving that it is possible to stream tonnes to video footage, dispite the bandwidth costs, and still make a profit. Maybe it's not profitable right now today, but presuming it received enough customers I would be surprised if it wasn't profitable within a few years.

Well, I think WebGL shows that the current direction is doing only the rendering on the client (mobile devices have enough graphics processing power to render 3D in a quality suitable for their small screens) and leaving everything else (AI, physics and, obviously, multiplayer) to the servers. This is making the best of current "terminals" and bandwidth strengths and limitations.This actually bodes well for Java (the platform, not necessarily the language) as it is by far the most successful server platform.

As for the client, well, JavaScript seems to be the direction, though I wish it wasn't so. At least I hope that we'd get something like GWT for JavaFX - something that would compile JavaFX Script to HTML-JavaScript.The reasons for this, I think, are not so much Java's limitations - it would have been far cheaper (for Google, for example) to fix Java's loading time on the client rather than develop a whole new standard with far fewer capabilities - but rather simple politics. A huge company such as Google cannot afford to stake its future on a platform controlled by another company.If Java were to be completely freed, perhaps Google and others would be happy to use it rather than JavaScript, but where is the upside for Oracle?

I think you missed the bit where "youtube quality" won't cut it. Also you tube can encode outside real time. You can't do that with a interactive FPS game which means *much* higher bandwidth for a given quality.

I have no special talents. I am only passionately curious.--Albert Einstein

I think you missed the bit where "youtube quality" won't cut it. Also you tube can encode outside real time. You can't do that with a interactive FPS game which means *much* higher bandwidth for a given quality.

Where I used to work we had a weekly video conference with another team in a different country. The footage was always to a high standard and practically real-time. BBC iPlayer is another example, it too streams video at much better quality then YouTube in almost real-time. I expect the delays in both of my examples would only be acceptable for the slowest paced games. But they are examples of where real-time video streaming is being done, today, to a high standard. Clearly the price has also not prevented them, and there are plenty of other services who offer similar.

A gaming version would need to improve on this, to have much lower latency during compression and decompression. However hardware is still getting more powerful year on year and GPGPUs are starting to become more common in servers. You might need high-end hardware but again I see no reason why you can't do this today, where the majority of the latency is in the network.

I think you missed the bit where "youtube quality" won't cut it. Also you tube can encode outside real time. You can't do that with a interactive FPS game which means *much* higher bandwidth for a given quality.

For mobile devices with small screens, youtube quality is enough. Yes it must be compressed in real-time as opposed of multiple-pass encoding possible when encoding it offline, but also, game display output is much more predictable than random videos up on youtube. The MPEG-4 standard even contains possibilities for encoding videos with well-known properties, such as frame movements, even 3D functionality. Don't know how much of that is contained in H.264 or Theora, but it should be eventually. And that may provide compression speed/quality well beyond what can be achieved with random videos.

I was referring to addition complexity needed in 3D games. Think physics, etc. Whatever performance JavaScript has, it was not made for such things. And running such things on the desktop (in JavaScript) is also problematic, and in the article I've read, the iPhone JavaScript is 10 times slower than on a netbook. The 3D display may work properly (its hardware accelerated no question), but with CPU performance 10 times slower than a low-end desktop, it will not run the additional computations needed for a 3D game. Android may be better, but i doubt even it has enough processing power.[...]

First of all, most games do not need heavy physics calculations (the PlayStation1 and the N64 were perfectly fine without it). Also, this isn't about AAA with a multi million dollar budget.

>[...] in the article I've read, the iPhone JavaScript is 10 times slower than on a netbook.

Depending on how they benchmarked it they may have benchmarked a completely different thing. E.g. if you do DOM manipulation, the JS code only contributes to like 10% of the time. It also didn't compare it to Java. On Android devices JavaScript (V8 - generates native code) is probably about as fast as Java (Dalvik - currently no JIT).

Still some time before its released and then a lot of time before the phone companies start updating. But hopefully since it has a few nice things from what I hear, the update will get out quicker or there's going to be a lot more demands(I saw a ton of uncontrolled demanding for 2.1 for droid/milestone and that update was crap).

I think that Java applets are by far the best technology for heavy applications in the browser, esp. with the recent improvements to the plugin, but it seems like some big players out there just won't have it. Apple won't allow any client middleware, and while Google is adding Flash to Android, it seems like they're only doing it to look nice compared to Apple, as they know Flash's days are numbered. Microsoft has its own technologies and its own problems. Which leaves Java without a strong consumer-facing backer.Java developers should find it even more frustrating to see Google's "Native Client" (released yesterday as a dev preview - http://code.google.com/p/nativeclient/), which allows running applications compiled for LLVM (rather than the JVM) in the browser. I doubt it will have better performance than Java applets, especially once the JRE is modularized, and it is certain to deliver a far worse development experience and perhaps problematic security. Like I said before, the big players won't put their weight behind an Oracle (or Sun for that matter) controlled technology. So perhaps kapta is right, and in the near future Java is facing some bright improvements, but it probably won't last. This is another case of the best technology losing to politics. That is, unless Java were to be truly freed of its corporate ownership...

But Java will continue to grow strong on the server, where it seems most of the exciting stuff will be happening anyway.

The key question is what will Oracle do to/with Java in the next year. This next year is critical as new markets continue to emerge (like mobile and pseudo-mobile devices). And so far, Oracle has done close to nothing on the evangelist side of things, leaving most of us pondering if this is the end of Java (it's not). Though the sad reality is, Java is losing market pull. More and more groups are moving away from the "unsure" thing and going with something that seems more stable and more forward-thinking. This is the whole reason why Mono exists, because Java was closed and Sun didn't have open enough communication to calm people's fears about it's direction. Microsoft decided to go it's own way (which is what it wanted to do with Java as well), and people actually had more "faith" in Microsoft than they did Sun.

This last year, with the Oracle buyout, Java started slipping again (the uncertainty of corporate buyouts almost always causes staggered growth). Then, key Java figures (in the popular opinion anyway) left the company. Oracle is infamously quiet (almost silent) with their communication, focused on the bottom line, and charging/over-charging anyone in anyway possible. So, what are they going to do now? No one knows, and that's the big problem, as we're left to make up stories about what the possible outcomes will be (the vast majority being highly negative because of Oracle's past practices).

SO... if you really want to know what the future holds, and if you should be programming in Applets or something else... wait a year and see. Although I personally, very much doubt that Applets will be a viable future platform, even though they work just great for now.

I think that Java applets are by far the best technology for heavy applications in the browser, esp. with the recent improvements to the plugin, but it seems like some big players out there just won't have it.

I second this. If you want to make a bespoke, big app that can be deployed via the browser then Java is an excellent choice. If you want something light, cheap and cheerful which 99% of people can play in the browser then there are plenty of better alternatives to Java. Worse of all they are under far more advertising and active development.

Well, will see what Oracle wants to do. They announced many months ago that they want to invest in JavaFX among VM performance.

Ah, but that was before the deal had been signed and approved. Now Oracle own Sun it's a very different world. I personally think JavaFX will continue, but it will be aimed almost entirely at the enterprise world. For building the front-ends to Oracles many enterprise Java products, and for various companies own internal apps. Oracle specialise in enterprise products; I don't think they really care about what happens outside of that domain.

Great news. But it's a bit unfortunate that they only benchmarked it with the rather meaningless Linpack benchmark. Linpack requires less than 400 lines of code and it only consists of arrays, floating point math, and loops.

So, if you manage to improve array access or floating point calculations (e.g. by having an FPU at your disposal - which of course also is a huge advantage for JavaScript), you'll see a drastic jump in that benchmark.

But still... 37.5 MFLOPS is pretty impressive. I just wish they'd used a somewhat more complete test. E.g. the Shootout benchmarks would have been nice. While they are all micro benchmarks, they all got a slightly different bias, which in turn means you'd end up with a range which would actually translate fairly well to real applications.

Seems to be a solution in search of a problem. That problem was essentially solved a long time ago but for no particularly well explained reason some engineers have decided they want to solve it again.

To be honest, so far I found Canvas/javascript to be completely underwhelming. It's like going back in time 10 years, but worse.

Ye well, it's currently pretty slow. Especially in Firefox. Drawing one (translated) 640x768 and one (translucent) 480x480 image on top makes it already drop down to 32fps. (Resident Evil 5 runs in high quality at full HD resolution by the way... makes it somewhat embarrassing, really.)

Over at my 10 year old machine I could do the same @ >200fps with OpenGL accelerated Java.

Currently there are two big bottlenecks: a) the compositing and b) the drawing itself is very slow (the per draw call overhead is microscopic in comparison).

The drawing in Chrome is more than 4 times faster, which is enough to make it usable. Opera's drawing is only about 2 times faster, which is a bit meh.

But, as I already mentioned, this is a problem that will be sorted out in the future.

With WebGL the drawing itself is of course pretty fast, but the compositing overhead doesn't allow you to crank the resolution all the way up.

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