Nothing wrong with LWJGL, it all still works.
It’s just some behaviour of some things in 1.5 that has changed. Granted, some of it might be my own fault (I admit that directly including org.apache.xpath.XPathAPI in Cosmic Trip wasn’t exactly smart), but still…
I think using XML for game is a bit silly, some smarter custom format is much better.
Sound problems? Could it be sign they repaired Java sound or is it still not completely smartly done? They should iron it properly.
XML’s just a bit convenient is all.
Cas 
[quote]I think using XML for game is a bit silly, some smarter custom format is much better.
[/quote]
In most cases, I don’t think there’s anything wrong, not smart or even silly about using XML.
I got shitload of code at work which can run only on 1.3 and not 1.4, and 1.4 code which can’t run on 1.5 … (mostly client applet code) so if the customer upgrade the JVM … kaboom… plus it’s not my code, it’s third party propietary one, so I can’t upgrade it :-/
Which is one of the reasons applets and webstart suck for game distribution. JVM upgrades break code too often.
The only way to be sure your code will be working one year from now is to either use a native compiler or use an embedded VM.
Things that makes you go hmmmm… :-/
[quote]Which is one of the reasons applets and webstart suck for game distribution. JVM upgrades break code too often.
[/quote]
What? ???
You can specify the exact version of the JVM or an entire range of JVM versions for JWS. There are other things that suck about JWS, but JVM versioning is not one of them.
God bless,
-Toby Reyelts
Except overhead, and problems to memmap the file.
If I would use an XML for that few maps, I would get in worst case instead of 2 TB at least 20 TB.
Of course there is one rule when you are using external libraries. Be carefull.
[quote]What?
You can specify the exact version of the JVM or an entire range of JVM versions for JWS. There are other things that suck about JWS, but JVM versioning is not one of them.
[/quote]
So, say a casual user has gone through the lengths of downloading the huge 1.5.0 JVM and your code specifically asks for 1.4.1, he has to download a huge JVM again. He starts another game asking for 1.4.2, another huge download. If the casual user was just curious about the games in the 4k competition, well imagine his joy…
And in applets, you can’t specify a version.
of course it’s not as bad as I make it look now, but my point is that this exact versioning shouldn’t be necessary. It would be nice if I had a game developed in 1.3, it would still work without thinking about future incompatibility problems. Now realisitically, shit happens, but JVM incompatibility problems have affected me a little too often.
[quote]Except overhead, and problems to memmap the file.
If I would use an XML for that few maps, I would get in worst case instead of 2 TB at least 20 TB.
[/quote]
As always, it depends on what you’re using it for. The right tool for the right job and all. In the end, XML is just another format, and a pretty convenient one.
- The JVM is not huge. It’s actually pretty small. People don’t download the JDK, they download the JRE.
- People don’t casually download JVMs. They download a JVM to run an app.
- If you want to let your users run your app on an “uncertified platform”, that’s your choice. You can always write another JNLP that says "run my program on any JVM version, but it’s not certified.
- The whole idea that you can magically run your apps on a new platform and never expect any incompatibilities in the upgrade is basically ludicrous. This has nothing to do with Java - it’s a general software reality.
God bless,
-Toby Reyelts
- for me and my internet connection, it is
- of course. I don’t know how this relates to my point
- ok, that might be an option for web start
- of course; that’s what I meant with my “shit happens” comment.
My main point is that JVM incompatibilities happened a lot more to me lately than I think would be ‘as expected’. So right now I’m in “pissed off trolling mode”, that’s all. But maybe I should just shut up and just fix all my code… again. Or just let my users screw themselves for a while, while I read a book and calm down
I can’t play about half of the 4k games; I assume its because of 1.5/jws. I will not install the 1.5 jre/jdk on this machine. Oh, well. :o
Well, I’d assume that as being your fault for not keeping up to date.
I think the issue is how the later JVMs aren’t keeping much backward compatability. :\
- The download issue goes like this:
- webstart revolves around the idea of making the JVM a shared, dynamic, library, something that each app doesn’t need to provide a private copy of.
- if there are relatively few versions, and lots of applications, then most users will nearly always already have the required JVM version
It works because there are many more apps the user downloads than there are JVM versions they might realistically use. At any one time, there are typically only 3 valid JVM versions in existence (for windows and linux) - latest, latest-but-one (due to x.x.x_YY regression bugs - with 1.5 still so young, this is applied to the 1.4.2 at the moment instead), and previous-platform (i.e. 1.4.2 at the moment)
There’s really nothing to complain about here: either there are enough games/apps that it works, or there aren’t. Why was JGF created? Partly to put a large amount of such games/apps in one place, because doing so makes webstart “work for the user”. If you find yourself saying something like: “my users keep being asked to download more JVMs all the time” this is really a reflection of the fact that they haven’t upgraded when they should have (ignored the auto-update in windows!) or that your JNLP’s are wrong, referencing out of date crappy JVM’s, or that your code is wrong, relying on bugs in the standard libraries WHICH YOU NEED TO FIX RATHER THAN RELY ON THEM.
- There are almost no incompatibilities with “real” java versions, the ones that people use in production (i.e. 1.4.2 etc). Just because a lot of developers are (mostly without thinking much about it, I suspect) switching to 1.5.0 doesn’t change this; most people are not doing this precisely because they/we know that this has never been a good idea with any Sun software ever, and has always caused large amounts of pain.
Although, I suppose I ought to be grateful that you lot are beta-testing the JVM so that eventually it will make it to 1.5.1 or 1.5.2 or 1.5.3 and become “usable”.
Um, except of course the mind-numbing: “We created chaos and confusion by releasing 1.3 so that the compiler produced stuff that crashe pre-1.3 JVMs. Because we’re so stupid, let’s do it all over again! We didn’t quite get enough bad press about how crap java was last time (heck, there was a lot, but it blew over after a while; we need some more free publicity!), so let’s really roll out the barrel this time”.
/me thinks the shareholders of Sun Microsystems really need to start firing some of the morons they employ
-
Java 5 is most definitely NOT something “up to date” that users ought to be upgrading to or else the bugs they experience are “[their] fault”. Despite the begging of high-level Sun executives, relatively few people with wisdom on their side have migrated to java 5 for production use; Sun hasn’t magically become the only tech company in the world to release 1.0 of a new language version without lots of major bugs.
-
Webstart lets you specify multiple JVM versions in parallel: that means you can, for instnace, tell it to pick 1.4.1 if available, but if not to accept 1.5. Not very useful for normal people, I suspect, but it does mitigate against the version incompatibility problem if you know people are likely to not uninstall the old JVMs. I have very little faith in them leaving them around, so don’t use it myself.
-
You shouldn’t ever write a webstart for 1.4.1 etc; the same goes for most other “not quite latest” versions. 1.4.1 is so ridiculous buggy that the user MUST upgrade ASAP, unless they have a corporate desktop or similar that locks everyone on that buggy piece of ***.
…webstart for a.b.c_XX is an entirely different matter, of course. There are regression bugs in the XX releases you sometimes need to manually work around by specifying allowed XX’s in your webstart. Just be grateful that webstart lets you do this!
If they’re webstart applets you can
Just forget about Webstart outside of vertical applications and this forum, ok? No amount of convincing me is going to help. I’ve got facts and data.
Cas
[quote]Just forget about Webstart outside of vertical applications and this forum, ok? No amount of convincing me is going to help. I’ve got facts and data.
[/quote]
I wouldn’t dream of trying to convince you :
…but I’m a lot more optimistic about webstart, and a lot more confident in the network effect: if/when adoption hits the right threshold, it will be fine as a distribution medium (in the same way that Java is fine as a dev platform: still has plenty of “ARRGGH!!” stupid design mistakes that Sun refuses to fix, and plenty of bugs - but good enough that we, the devs, get a noticeably easier life and can do most of what we need to do to make profit).
The threshold unfortunately is somewhere near to “ubiquity” and even then it won’t help - people do don’t like the whole concept of Webstart. Even I don’t like it. When I buy something I want a package I can download and backup somewhere permanently that doesn’t auto-upgrade itself. It looks like everybody else likes it like that too.
Furthermore Webstart plays havoc with conversion rates precisely because of the tiny investment that people have in downloading and running something. As a shareware delivery platform, it’s a disaster - converting at less than half the rate of the otherwise 100% identical embedded VM versions.
Cas
[quote]The threshold unfortunately is somewhere near to “ubiquity” and even then it won’t help - people do don’t like the whole concept of Webstart. Even I don’t like it. When I buy something I want a package I can download and backup somewhere permanently that doesn’t auto-upgrade itself.
[/quote]
I think it could only work in a subscription-like situation where you are constantly connected to a service.
Just a few things I’m thinking of that might improve JWS’ acceptance:
-
Improve desktop integration. Let the user choose a program group and let the desktop icon be just an option. Ideally, user’s should never have to start the jws application manager, because it basically just sucks. They already have their own “application manager” (their os) that they’re used to and don’t need another, crappy unfinished one.
-
Have an option in jnlp to always do desktop integration instead of the “do you want desktop integration?” dialog. It’s just an annoying pop-up most of the time.
-
Have an option in jnlp to disable auto-update. With desktop integration, this could be simply a manual action by use of an extra menu item “check for update”.
-
Have an option to let the user where to install the ws application, so in effect make another directory part of the jws cache.
Thoughts?