[I am Har har har]

I'm having to learn Java, and I have some questions:

A. Is it a fast or slow language? (In comparison to languages like Qbasic and C)

2. Does it have a standard graphics library? QB has one, but C++ does not. I find that a standard graphics lib simplifies things quite a bit.

C. Does it have better sound routines than QB? In every one of the QB Sound libraries I've seen, the sound would not work on a system with on-board sound (A sound card built into the motherboard.) It only worked with Soundblaster cards, also.

4. Does it have good library support? I expect it will, but you never know.
_________________
I do what I like. Do you have a problem with that?

[LeoDraco]

[Bjorn]

I don't think he needs JMF unless he wants to create a media player, or integrate movies in his game. Java has a 2D graphics api in its standard library. There is also the optional Java3D for 3D graphics. I don't know about sound, maybe you will need JMF for that...

The speed of Java doesn't have to be an issue depending on how you use the language. It's like extending your game with a relatively slow scripting language: you expect the time spent executing the scripts to be rather low, so speed doesn't matter than much. With Java, the standard library should be fairly fast while your own custom code will be relatively slow. So make sure you rely on the high level functionality of the standard library as much as possible.

[I am Har har har]

How much faster is Java than QuickBasic? How much slower than C? Keep in mind that I'll be using it as a true programming language, and not in web scripting.

Another question that bugs me...why don't any of the QB sound routines I've seen work with onboard sound? Can't they work with cards beside sound blasters?
_________________
I do what I like. Do you have a problem with that?

[valderman]

Tha latest Java versions are actually faster than C code compiled with GCC in some cases. MSVC .NET produces slightly faster code in all circumstances (IIRC), but not by much.
_________________
http://www.weeaboo.se

[Bjorn]

About the sound stuff not working in QB. As far as I'm aware QB is an ancient language+ide and hasn't been brought up to date with modern ways to use the hardware, namelijk through hardware abstraction layers provided by the operating system such as various sound card drivers all the way up to DirectX. If you want support for new soundcards in QB, you're basically asking for DOS drivers that basically make your soundcard behave like an SB16 compatible. Of course few sound card vendors are still providing those, if any at all, because there simply isn't any interest anymore.

That Java would be faster than C is theoretically impossible I think, because the Java code is compiled to bytecode and then executed by the JVM which is itself done in C or C++. Of course parts could have been done in optimized assembler, maybe making a marginal gain in speed but it'll only be in the standard library, not in the speed of execution of your own code.

[janus]

[Bjorn]

Right, of course Java can be faster than C, if you assume the algorithm is implemented more efficient in the Java case.

[valderman]

The VM part isn't inherently a slowdown. Take Longhorn, for example. I've come to understand that CLI code executes notably faster than native code.
Of course, this is because the OS itself is nothing more than a wrapper around the .NET framework and Palladium.
_________________
http://www.weeaboo.se

[LeoDraco]

A lot of it, though, is dependent, inherently, upon the architecture that the code is being ran on. At some level, the code has to be translated into binary, and ran on the system. And, you cannot simply look at two programs that do the same thing that are written in two different languages for comparison; you have to look at a variety. I've not looked over all of the data, but SPEC should have all the data needed for a logical comparison.

I, personally, do not see how Java could be faster; Java code is compiled for the JVM, for portabiltiy and standardization reasons; the JVM itself, at some point, is going to be required to translate its own ISA into the underlying systems ISA; in comparison, C-code that is compiled natively on a machine is already translated into the local systems ISA.
_________________
"...LeoDraco is a pompus git..." -- Mandrake

[valderman]

Since Java is compiled just before execution, the VM can optimize the code for the system it's running on. That's a pretty good advantage over native code, though it isn't used all that much to my knowledge.
_________________
http://www.weeaboo.se

[Bjorn]

[valderman]

For example, the architecture of the latest AMD CPUs' pipeline is different from that of earlier AMD CPUs, Pentium 1, 2, 3 and 4, and any other x86 compatible CPU. Same with video cards, memory architectures and operating systems.
Naturally, code that's optimized specifically for a certain OS, CPU or video card will run better on that configuration than code that is optimized for the entire current generation of video cards or CPUs.
Older Intel CPUs outperforming otherwise far super AMD CPUs in Quake III is a good example.

Naturally, it isn't possible to write thousands of optimizers to cover all possible configurations, but even if it's only the CPU there still is an advantage.

EDIT: Java isn't overall faster than C - with garbage collection and all, that just isn't possible. However, the VM-ized nature of the language isn't an inherent drawback (not since JIT compilers came around).
_________________
http://www.weeaboo.se

[Rainer Deyke]

[Rainer Deyke]