OpenGL also takes us one step closer to porting graphical DS clients to non-Windows machines.

multi user gaming universe no
its multiusergraphicaluniverse
i like what i thought the name stould for
at least multiusergaminguniverse has the word gaming in it

Crispy wrote:

Hiead wrote:

Good news is that it's in Java, and so too shall it fail horribly.

It's even using Swing for its GUI, by the look of it. Egads. Are they masochistic or what?

And people complain about BYOND being laggy... just be glad it's not written in Java, using Swing!

Java as a fact is not as slow as most of you seem to assume. Especially for GUI applications (with not extreme graphical 3D environments, that don't happen to inhabit BYOND as well :p) it supplies a suitable speed i written and compiled in a performant way.
I think every BYOND game on the hub could be rewritten in Java without anyone noticing an additional delay.

Oh and I'm not against BYOND. I like and support it (as a member), but I think you should stay fair.

Echi wrote:

I think every BYOND game on the hub could be rewritten in Java without anyone noticing an additional delay.

I agree.

Echi wrote:

Java as a fact is not as slow as most of you seem to assume. Especially for GUI applications

*cough* *splutter*

IMO, GUI applications are its weakest point.

I think every BYOND game on the hub could be rewritten in Java without anyone noticing an additional delay.

Granted, Java is faster than BYOND (for raw computation at least), and that was a cheap shot I made. =) But it's still the wrong choice for a gaming system (and I think it would still run badly on a Pentium II, for example - which BYOND runs fine on, I tried it).

The Java language isn't slow by itself (so most synthetic benchmarks will rate it as being quite fast), but the "Java way" of doing things is horribly inefficient (you have to create and garbage-collect several objects just to read a file, for example). Swing is an excellent example - it's so bloated that it couldn't help but be slow in whatever language it was implemented.

Ever tried to maintain a Tomcat server? (It's a web server that runs Java programs, much like CGI.) I installed Tomcat on a work server once to try out some kind of web application that we were investigating. Tomcat took about five minutes just to start up, and this is not a slow machine we're talking about. (Compare that to a few seconds for Apache.) I have a friend who works in a Java shop, and they use Tomcat on their servers. Big, beefy industrial things with multiple cores and several gigabytes of RAM. They frequently require rebooting.

Whenever I try to load a Java applet in Firefox, the browser locks solid for 20 seconds. This is on an Athlon64 3500+ with 2 GB of RAM.

And finally, maybe I'm in the minority here but I just find coding in Java to be hell. It's verbose and ugly and irritating. Forcing people to wrap everything in classes is not good language design; object-oriented programming is a useful tool, but it's not the holy grail. The "one class per file" rule sounds like a neat idea at first, but quickly becomes annoying.

From where I'm standing, there's not much to like about the language.

Ugh. Sorry about the rant, but I hate it when people get all starry-eyed over Java. It's not all bad; if it had become a niche language used for research purposes or stayed on mobile phones then it would be fine. Sadly, Sun's marketing department has a lot of money.

Oh and I'm not against BYOND. I like and support it (as a member), but I think you should stay fair.

I'm speaking from a personal, up-front, in-the-trenches perspective. Can't get much fairer than that.

I agree fully with Crispy - Java is slow, sucks memory, and is horribly to write in.

I'm doing a computer science degree at a university in Australia. I am just finishing up first year right now. In first year, we do the subjects Computer Science IA and Computer Science IB.

We use Java in both these subjects.

Basic programs written to, say, draw a fractal tree, lock up noticeably when you move the window around, causing it to redraw the tree - and all it does is draw a few lines on the screen. All the line endpoints are already processed and stored - the drawing code just whacks it down.

We had a practical in which we had to write an AI program to drive a virtual 'tank'. It's a little 2D game called Robocode. The tanks are written in Java.

This is a simple, 2D, top-down view, and the game (Also written in Java) runs at less then 10 FPS on my system at home. That's slower then BYOND. And it's mostly the drawing code that does it.

My system isn't exactly crash-hot - it's a Celeron 1100A processor with 512 MB of RAM, and I'm running this program in Win98SE - but it's still ridiculous.

Hiead wrote:

But Java is slow as a language! Much slower than C++.

I never said anything different :)
What I said is that in usual GUI applications (as would be the BYOND games we was discussing, since the thread was originaly about a BYOND 'doppelgaenger')

Hiead wrote:

Even the compiled versions of it pale to compare with the compiled C++ in most areas.

You can say that as an average amount a well written sourecode with precompileing is about two times slower than written in C/C++.
However, I can say out of own experience, most BYOND games (includeing hosting them) uses up less than 20% of my CPU.
And I'm useing a semi old Laptop (1.7 GHz M740 Pentium, 512 MB DDR2 RAM, WinXP to name the most important).
I think most BYOND users have a computer that can match this.

Hiead wrote:

As a programming language, Java may seem more friendly to some, being that it is 'easier,' but as a practical language in a world where not everyone can afford high-powered machines and where the common person likes to multi-task applications, Java is not quite as practical as a resource-friendly application resource.

I do not think Java is easier than other languages.
Actually I think achiveing the same effects is most often more complicated due to security issues and restrictions.
Btw. Java can multitask :p
And Java has a main benefit I like.
Security.

Echi wrote:

Crispy wrote:

IMO, GUI applications are its weakest point.

As a matter of fact, I excluded any compute intense graphics in my post (e.g. 3D graphics).
If you take that into consideration, GUI applications more often than not wait for user input.

Sure. But Java applications (more particularly, Swing) often make the user input wait for the GUI to redraw itself. =P

I don't want to judge this. But from my own expereince with both, I can tell that performant code in either does not use my full CPU resources.

Well obviously you're not doing enough computations to stress it out then. =)

Take Runescape as example. It's written completely in Java and runs fine on a P2 :p

Never played it, don't want to, so I can't contest this. It is possible in theory to write fast Java applications, but you have to avoid most of the standard library whenever you can, which makes things hard.

Hmm, Java runs in a VM. That by default makes is slower than any native could. The reason that the 'Java way' is wiered and inefficient in severel cases is both, platform independence and security issues.

Java's VM is not what I'm talking about. When I say the "Java way", I mean the "Java way of programming". Which is "never do something with, say, a function call when you can use 5 different objects". That kind of programming philosophy will drag any system down, whether or not it's running under a VM.

I saw some benchmarks once that claimed that Java could create objects twice as fast as an equivalent C++ program. Whether or not this is true, it's irrelevant, because Java programs make a lot more objects than C++ ones do! (On the order of 10-20 times more, at a guess.)

I would hesitiate to download the same C game from an unknown user, whereas I would not hesitate with the Java code.
Simply because, even though not 100% true, it is hard for malicious code to inflic damage in Java ;)

Depends what security model you're using. Applets are relatively safe, but desktop Java applications can link into compiled C code (which is a good thing, because it gives developers some opportunity to escape the grasp of pure-Java libraries). Not so sandboxed now, is it? =)

I don't like or use Swing.
We're of the same opinion there :p

Glad to hear it.

I wasn't saying that Java was nay match to C consiering speed or resource managemant. I said you would not notice a difference in the project that was discussed by the threadstarter. If you want to discuss something else, my agrumentation would be different and lead to different conclusion :)

Okay, fair enough.

Whenever I try to load a Java applet in Firefox, the browser locks solid for 20 seconds. This is on an Athlon64 3500+ with 2 GB of RAM.

What kind of applet and what Java do you have installed?

Any applet (even lightweight ones designed to demonstrate mathematical concepts, which one of my lecturers last semester liked to use), and Sun's standard Java VM.

And please note that you would have to start the applet local downloaded, as else you'll have to consider the download wich will *considerbaly* slow down things.

That's probably it, then. It shouldn't be designed so it locks up the browser while the applet downloads. That's pretty shoddy, especially given that Java has pretty solid thread support (it has to - they're used a lot!); and Flash doesn't do it, so it doesn't seem like it could be Firefox's problem.

Crispy wrote:

Sure. But Java applications (more particularly, Swing) often make the user input wait for the GUI to redraw itself. =P

Reducing Java to Swing is somewhat 'narrow minded'.
Honestly, no sane Java coder would use Swing, unless forced to :p

Crispy wrote:

Well obviously you're not doing enough computations to stress it out then. =)

You missunderstood me again. My whole point was in comparing a Java based BYOND like game to a BYOND game as is now. (As the thread *IS* about a BYOND doppelgaenger... and not about Java as a programing language. I would agree with you at any given time that Java should not be used for code that requires a lot of computing. Since that is not what it was designed for.)

Crispy wrote:

Never played it, don't want to, so I can't contest this. It is possible in theory to write fast Java applications, but you have to avoid most of the standard library whenever you can, which makes things hard.

Well :p
What should I comment on this, you're agreeing with my point, laughs.

Crispy wrote:

Java's VM is not what I'm talking about. When I say the "Java way", I mean the "Java way of programming". Which is "never do something with, say, a function call when you can use 5 different objects". That kind of programming philosophy will drag any system down, whether or not it's running under a VM.

I don't want to judge this, as I think the deep insight needed is beyond my capabilities.
But I can tell you, if you are only arguing with benchmarks, speed, resources and the way of programming, you would be forced to use Assambler as language of your choice. Since a performant written assambler code will beat any C or C++ code.
And I think it's not part of the threadtopic :)

Crispy wrote:

Depends what security model you're using. Applets are relatively safe, but desktop Java applications can link into compiled C code (which is a good thing, because it gives developers some opportunity to escape the grasp of pure-Java libraries). Not so sandboxed now, is it? =)

Sorry, my fault, I assumed it was an applet that we've been talking about. I confess I didn't take a deeper look into that project than the few Screenshoots posted.
Yes, you are right, Java applications can be dangerous (through still more save than natural C code if you apply and enforce the right security measures in your Java VM, since all code *IS* run inside the virtual machine and this is soley controled by you ;)

Crispy wrote:

That's probably it, then. It shouldn't be designed so it locks up the browser while the applet downloads. That's pretty shoddy, especially given that Java has pretty solid thread support (it has to - they're used a lot!); and Flash doesn't do it, so it doesn't seem like it could be Firefox's problem.

Hmm, I'm unsure here what you call 'lock up'.
Do you mean you can not interact with the part of the homepage that was reserved for the Java applet, or do you mean your complete browser refrains to work anymore, or does your system stall as a whole?
If you mean the browser locks up, I'm sorry, it's a shared problem :P
Firefox seems to have slight troubles with Java (at least for me, I guess the Firefox coders shared your antipathy for Java and thus treated it's plug in rather as a step child ;))
And it sounds to me as if you would use the 1.2 or even the 1.1 VM. Those, like most early versions that was finished in a rush have some troubles. Try 1.4.1 / 1.4.2

Exophus wrote:

Are there any screenshots of DUNG around? I've never seen what it looks like.

Must... resist... :P