oNyx
|
 |
«
Reply #30 - Posted
2010-12-11 11:46:33 » |
|
[...]I'll be able to deploy applications with V8 embedded and they'll run anywhere.[...] Heh. Yea, V8 is pretty much like that small junk-free VM you always wanted.  By the way, the Windows binary of the V8 shell is only 1.5mb in size (lzma'd 500kb). [...]LWJSGL anyone?[...] It should be pronounceable. Talking about LWJGL is amazingly painful. Adding one extra letter won't help. 
|
|
|
|
Riven
|
 |
«
Reply #31 - Posted
2010-12-11 12:19:52 » |
|
Scroll to the bottom, it reads "These statistics are based on W3Schools users." That means isn't not representative for the regular user at all.
|
Hi, appreciate more people! Σ ♥ = ¾ Learn how to award medals... and work your way up the social rankings!
|
|
|
princec
|
 |
«
Reply #32 - Posted
2010-12-11 12:37:45 » |
|
Well, for me, it's all about paying customers. Still got IE6 == skinflint with no money, sod off. Cas 
|
|
|
|
Games published by our own members! Check 'em out!
|
|
kappa
|
 |
«
Reply #33 - Posted
2010-12-11 13:48:32 » |
|
LWJSGL anyone?
It should be pronounceable. Talking about LWJGL is amazingly painful. Adding one extra letter won't help.  hehe, was thinking the same thing. Something should be done to make LWJGL easier to pronounce/remember, maybe drop the 'W', since lightweight is technically one word, so you end up with LJGL.
|
|
|
|
princec
|
 |
«
Reply #34 - Posted
2010-12-11 14:02:40 » |
|
It's not really very L any more either. It's just JGL. Which would work nicely for javascript too wouldn't it  oNyx - you got anything cool working with a standalone v8? Care to share? Cas 
|
|
|
|
lhkbob
|
 |
«
Reply #35 - Posted
2010-12-11 17:06:02 » |
|
But it's also open source, so why not add in an O to get Java Open Game Library  (whisper: this is only meant to be humorous, I am not biased towards either JOGL or LWJGL)
|
|
|
|
JL235
|
 |
«
Reply #36 - Posted
2010-12-11 18:19:39 » |
|
Nothing beats native apps in performance, capabilities and integration, also client-side apps are more stable (eg. GUIs typically work more as expected than DHTML/AJAX heavy apps) and not dependant on network latency or requiring to be online.
I disagree. Anyone who has used a PC has had native apps run slowly, buggy and crash on them. I'd personally say that brower apps going wrong is typically less intrusive; you just hit F5. Today I'd agree that good native apps beat good browser apps. But within only 6 months all of the main browsers will have good HTML 5 and CSS 3 support, hardware accelerated graphics and a JIT compiler for the JS (even for all three of those IE). Things like WebSockets will also make AJAXy sites much nicer. There are people today who play most of their games in the browser. I personally use Google Docs instead of MS Office as I mainly work on a very low end machine. It's just really nice not to have to have applications installed. Maybe because Java allows to do more serious things  I've written applets that work fine on Windows and will take down the entire browser on MacOS. I've written applets that run fine on Vista and Win7, but crawls on XP and Linux (same hardware).
|
|
|
|
Mr_Light
|
 |
«
Reply #37 - Posted
2010-12-12 03:50:00 » |
|
Best thing to ever happen to the JCP.
I mean really, apache guys wanted to make a point, point made and now we can move forward and can crank out specifications again.
"but these will suck" who-f**king-cares.
Let me point out: EJB there where other versions once.. which didn't make all ppl happy which gave birth to spring. Now take a look at version 3 -> Good or bad specs it will lead to improvement. JPA, that wasn't invented there, hibernate anyone? -> apparently things don't need to start in the JCP. Countless JSR's, who never got beyond a reference implementation and some didn't even got to one. -> Just because the JCP touched up on it doesn't make it law.
Can other ppl write specs and can these then be implemented by others?
The only thing that has changed at all is that language features now actually get run through he JCP which sun used to send down from the mountain. I mean, I like generics, but if others where to believed no one would ever use java 5.... so who is using a version java 5 or newer? hands please!
Besides even if they mess it up beyond everything imaginable, it only after that they've done that that we have to wonder about forking or migrating away.
|
It's harder to read code than to write it. - it's even harder to write readable code.
The gospel of brother Riven: "The guarantee that all bugs are in *your* code is worth gold." Amen brother a-m-e-n.
|
|
|
oNyx
|
 |
«
Reply #38 - Posted
2010-12-12 07:19:51 » |
|
It's not really very L any more either. It's just JGL. Which would work nicely for javascript too wouldn't it  oNyx - you got anything cool working with a standalone v8? Care to share? Cas  Tried to compile V8 for some ARMv5 (ARMv5TEJ/ARM926EJ-S [less obscure: for the GP2X Wiz homebrew handheld]) a while ago. After countless hours I finally succeeded, but the compiled binary failed at basic math. E.g. Math.log(5) worked correctly, but Math.log(5)+Math.log(5) didn't. Everything else did work though. I gave up at that point. Since I didn't know what the f- I was supposed to do about that. Well, ARM support (or more precisely: support for older uncool ARM CPUs) was a bit lacking back then. It probably works fine now. The plan was to create something simple which supports just enough of Events, Image, Audio, and Canvas to create a game. This would have allowed me to run my regular code on this device as well. After making the V8 shell run on that device the next step would have been a prototype of this "game runner" with Java, Rhino, LWJGL, and Slick. This would have served as some kind of proof of concept. It would have also shown which pieces are absolutely necessary and how everything fits together. The next step would have been to recreate this with C++ (GLES 1.1, libpng, libjpeg, and all that crap). Possibly with the help of other Wiz community members. Maybe I should give it another try. The only similar thing on that device is Pygame (CPython based), but it's unfortunately too slow for anything (and I also kinda dislike Python). As we all know, V8 is quite a bit faster than CPython. Even back then V8 would have been fast enough for most classic genres like platformers or puzzle games (CPython wasn't and still isn't fast enough). A friend of mine did succeed with something similar though: http://www.phoboslab.org/log/2010/10/impact-for-iosGenerally I do think that it would be nice to have some "game VM" for ARM based devices, Windows, Mac, Linux, and whatever else there might be. But I'd always try to mirror the browser environment as closely as possible. For one it means you can also use that code online (well... duh), but most importantly it also means that you can develop with browsers which is pretty convenient.
|
|
|
|
gouessej
|
 |
«
Reply #39 - Posted
2010-12-12 13:13:02 » |
|
I've written applets that work fine on Windows and will take down the entire browser on MacOS. I've written applets that run fine on Vista and Win7, but crawls on XP and Linux (same hardware).
That is why I don't write applets 
|
|
|
|
Games published by our own members! Check 'em out!
|
|
JL235
|
 |
«
Reply #40 - Posted
2010-12-13 17:49:39 » |
|
Supposedly Oracle is planning to have Java target JavaScript ( source). If this is true then I'll be very pleased and it might just be enough to rejuvenate Java development for the browser. YAY!
|
|
|
|
zammbi
|
 |
«
Reply #41 - Posted
2010-12-13 20:55:45 » |
|
Supposedly Oracle is planning to have Java target JavaScript (source). If this is true then I'll be very pleased and it might just be enough to rejuvenate Java development for the browser. YAY!
So they expanding to all of Java instead of just JavaFX. Though not everything could be supported like files but still very cool. 
|
|
|
|
Nate
|
 |
«
Reply #42 - Posted
2010-12-13 21:14:46 » |
|
Meh.
|
|
|
|
DzzD
|
 |
«
Reply #43 - Posted
2010-12-14 00:45:45 » |
|
That is why I don't write applets  that's why I stick on 1.1 ^^ lol, everythings continu to work well before thinking of new features java plugin MUST be put into a stable release that work EVERY WHERE... and get some utility tools ( studio like ) maybe a day Oracle (too bad to say Oracle rather than Sun) will considere this... javafx will probalby have got more succes if it was producing regular/standard java Applet code (as a studio) rather then bringing a completly new plugin that requiere installation
|
|
|
|
gouessej
|
 |
«
Reply #44 - Posted
2010-12-14 10:44:48 » |
|
that's why I stick on 1.1 ^^ lol, everythings continu to work well I find some workarounds on known bugs and it works quite fine too. before thinking of new features java plugin MUST be put into a stable release that work EVERY WHERE... and get some utility tools ( studio like ) maybe a day Oracle (too bad to say Oracle rather than Sun) will considere this...
javafx will probalby have got more succes if it was producing regular/standard java Applet code (as a studio) rather then bringing a completly new plugin that requiere installation
I agree with you and reinventing GWT is not a good idea. The best solution is still the use of a true JVM. JavaScript is still noticeably slower than Java. As far as I know, JavaFX 2.0 will have a true Java API (see the roadmap). Having a solution like GWT could be a nice complementary option but it should not replace the JVM.
|
|
|
|
princec
|
 |
«
Reply #45 - Posted
2010-12-14 10:46:53 » |
|
Being able to use jars as scripts always struck me as being something useful but no browser ever tried it. Cas 
|
|
|
|
kappa
|
 |
«
Reply #46 - Posted
2010-12-14 11:09:57 » |
|
JavaScript is still noticeably slower than Java.
Yes that's true, however at the rate its progressing and the stiff competition in the area, it doesn't look like it'll be long before performance catches up to hotspots.
|
|
|
|
JL235
|
 |
«
Reply #47 - Posted
2010-12-14 11:35:12 » |
|
JavaScript is still noticeably slower than Java. At lot of the bottlenecks for a lot of sites are also down to network latency, the speed of altering the dom and the speed of rendering. Web sockets should help to reduce network latency and all major browsers will have fully hardware accelerated graphics for rendering next year.
|
|
|
|
gouessej
|
 |
«
Reply #48 - Posted
2010-12-14 12:33:56 » |
|
Yes that's true, however at the rate its progressing and the stiff competition in the area, it doesn't look like it'll be long before performance catches up to hotspots.
But JavaScript is not as cross-platform as Java. Look at the source code produced by GWT... JavaScript cannot completely replace Java therefore it is still preferable to have a JVM and a fallback solution (JavaScript engine, JavaScript VM, something like GWT, etc...).
|
|
|
|
JL235
|
 |
«
Reply #49 - Posted
2010-12-14 12:59:52 » |
|
But JavaScript is not as cross-platform as Java. Look at the source code produced by GWT... JavaScript cannot completely replace Java therefore it is still preferable to have a JVM and a fallback solution (JavaScript engine, JavaScript VM, something like GWT, etc...).
It runs on the iPhone. For client-side that's a lot more desirable then Solaris or HP-UX.
|
|
|
|
gouessej
|
 |
«
Reply #50 - Posted
2010-12-14 15:54:32 » |
|
It runs on the iPhone. For client-side that's a lot more desirable then Solaris or HP-UX.
There are still other solutions to "run" Java on IPhone including ISpectrum, XMLVM, etc... I was not thinking about Solaris, I remind you that the JavaScript source code produced by GWT for each target shows that JavaScript requires much more efforts to support several browsers and it is even more obvious when you have to do it yourself without such tools. JavaScript could allow to support currently unsupported platforms including IPod, IPhone, IPad, etc... but it cannot completely replace a JVM and a true JVM would be a better solution. Whatever you do, Java emulated with JavaScript won't be able to do all things a JVM can already do and I don't think only about games inside the browser, actually I'm not interested in the browser. Finally I would prefer that Oracle concentrates its efforts on the JVM and tries to negociate with Apple to get a nice JVM + the Sensor API on IPhone, IPod and IPad. Until it is ok, there are a few solutions to convert Java into Objective-C. At lot of the bottlenecks for a lot of sites are also down to network latency, the speed of altering the dom and the speed of rendering. Web sockets should help to reduce network latency and all major browsers will have fully hardware accelerated graphics for rendering next year.
WebGL won't be on Internet Explorer http://learningwebgl.com/blog/?p=993The acceleration feature takes advantage of hitherto untapped computing power in a way that's more useful than other browser-boosting technology--Google's Native Client to directly employ PC's processor and Mozilla's WebGL for accelerated 3D graphics, for example--according to Dean Hachamovitch, general manager of Internet Explorer. Read more: http://news.cnet.com/8301-30685_3-10400638-264.html#ixzz186PbYdn1
|
|
|
|
JL235
|
 |
«
Reply #51 - Posted
2010-12-14 18:12:18 » |
|
I remind you that the JavaScript source code produced by GWT for each target shows that JavaScript requires much more efforts to support several browsers... GWT supports IE 6, FireFox 1, Safari 2 and other really old browsers. That's why it needs to go to such efforts. The types of places that still use really outdated browsers wouldn't be interested in 2D and 3D games running in the browser (or high-end apps). Those who are typically use a non-IE browser (although IE 8 is still really popular). So even though WebGL will be missing in IE9 I don't think this will really harm WebGL's future.
|
|
|
|
Roquen
|
 |
«
Reply #52 - Posted
2010-12-14 18:51:06 » |
|
Cas seems to be talking about embedding V8, which is very portable. So most of the last few post are OT for that situation.
|
|
|
|
kappa
|
 |
«
Reply #53 - Posted
2010-12-14 18:59:22 » |
|
Supposedly Oracle is planning to have Java target JavaScript ( source). If this is true then I'll be very pleased and it might just be enough to rejuvenate Java development for the browser. YAY! another source http://www.taranfx.com/java-javascript-runtime-environmentInteresting, something like this coming from Oracle is rather surprising as they might actually pull it off (unlike say from Sun).
|
|
|
|
gouessej
|
 |
«
Reply #54 - Posted
2010-12-14 19:16:12 » |
|
GWT supports IE 6, FireFox 1, Safari 2 and other really old browsers. That's why it needs to go to such efforts. Don't expect GWT to cover all features of Java. The types of places that still use really outdated browsers wouldn't be interested in 2D and 3D games running in the browser (or high-end apps). Those who are typically use a non-IE browser (although IE 8 is still really popular). So even though WebGL will be missing in IE9 I don't think this will really harm WebGL's future.
Microsoft almost succeeded in killing SVG in the past by not supporting it early enough in Internet Explorer. I'm sad but if MSIE 9 does not support WebGL, it will really harm WebGL's future. JavaScript is only a good fallback solution, not THE solution.
|
|
|
|
oNyx
|
 |
«
Reply #55 - Posted
2010-12-14 19:48:36 » |
|
But JavaScript is not as cross-platform as Java.[...] JavaScript works on any platform which supports Java 1.5+. Of course it also works on lots of other platforms as well. E.g. you could use it on the XBox 360, PS3, or even on the Nintendo DS if you really want.
|
|
|
|
appel
|
 |
«
Reply #56 - Posted
2010-12-14 22:27:03 » |
|
Don't expect GWT to cover all features of Java. Microsoft almost succeeded in killing SVG in the past by not supporting it early enough in Internet Explorer. I'm sad but if MSIE 9 does not support WebGL, it will really harm WebGL's future. JavaScript is only a good fallback solution, not THE solution.
It took Microsoft 10 years to support alpha channel in PNG images. Don't hold your breath for any fast adoption from that slow paced giant.
|
|
|
|
gouessej
|
 |
«
Reply #57 - Posted
2010-12-14 22:38:42 » |
|
JavaScript works on any platform which supports Java 1.5+. Of course it also works on lots of other platforms as well. E.g. you could use it on the XBox 360, PS3, or even on the Nintendo DS if you really want.
It does not provide all features that are already in Java and you will never have WebGL on XBox 360  Come down to Earth. Java to JavaScript solutions are nice complements especially on platforms that have no JVM but they don't replace real Java. If I was forced to port a game on XBLA, I would use IKVM rather than a solution based on JavaScript. You are not allowed to use any RSX driver on PS3 so you won't get a legal support of WebGL on it  Nintendo, Sony and Microsoft won't let anyone develop a nice legal solution that would allow to develop and deploy games on their platforms without paying their licenses for their own SDKs. This thread contains a lot of science-fiction  It took Microsoft 10 years to support alpha channel in PNG images.
Don't hold your breath for any fast adoption from that slow paced giant.
I know that. Sometimes it is not problematic for a given technology (PNG for example) but in some cases, it is the opposite (SVG for example).
|
|
|
|
Mike
|
 |
«
Reply #58 - Posted
2010-12-14 22:45:51 » |
|
I'm sad but if MSIE 9 does not support WebGL, it will really harm WebGL's future.
IE 9 beta supports SVG so that shouldn't be a problem.
|
|
|
|
gouessej
|
 |
«
Reply #59 - Posted
2010-12-14 22:49:47 » |
|
IE 9 beta supports SVG so that shouldn't be a problem.
Microsoft could have done it several years ago... Implementing it so lately was a way of killing this technology. If Microsoft plans to do the same with WebGL, maybe you will have WebGL support in MSIE 14 
|
|
|
|
|