Topic by Victorious 2014-11-13 18:17:59

  • Registered: 2010-11-08
  • Posts: 1,125
  • User Karma: 28

In my next semester at university, we'll be moving from using C this semester to data structures and algorithms next year using the java language. I know of some audio games that have been developed in java, and am wondering how good a development platform it would be. It would be an interesting way to practice for the practicals and such.Using java should make supporting multiple platforms easier, as it just has to be compiled once. However, i'm wondering about the availability of libraries for things like audio and such. In theory, java would also be slower than programmes written for other languages, though that probably won't be an issue. Thoughts?

Quote Post 1

Thumbs up

Reply by Aminiel 2014-11-13 23:06:33 (edited by Aminiel 2014-11-13 23:15:03)

  • From: Switzerland
  • Registered: 2008-12-24
  • Posts: 638
  • User Karma: 54

Unless you are really programming an high-demanding resource game, the slight speed difference wont play an huge role. The legend of java being very slow is no longer much true nowadays. Now the ratio is near 1.1 or 1.2 compared to C. The more real truth today is that python is now getting slower than java, and as you know there are a few big games developped in python, SoundRTS for example. So from this point of view, java is perfectly viable to run a game.

The biggest problem is to find libraries for audio, speech and such specialized things.
For speech, my library UniversalSpeech is normally compatible with java.
For audio however, you have the choice between two quite bad options: use a library based on JavaSound and it's quite a pain to have something really good sounding, or use a java port of a well known library e.g. joal, BASS native, FMOD, and there the problem is performances because the JVM make frequent calls to C backends.

If interested, a few years ago, I developped a small audio library based on JavaSound. As already said, it's quite limited because JavaSound is itself quite limited, but if you don't need advanced effects or full 3D, it can suffice. It was sufficient for my game MagicBlocks, and more generally I think that for a simple arcade or side scroller game, it would be perfectly OK.

Another important point against java not to be neglected is its JVM, which has necessarily to be installed separately. Java isn't always installed everywhere and many people have issues installing it, even if they juste have to do I accept next next next finish. So it might, wheither or not you want it, limit a little your audience or you will perhaps have to make more support on how to install the JVM and its dependencies. The size of the JVM make also quite impractical for you to bind it together with your application at the end, opposited to other VM-based languages like python, where it is much easier to do it because the size of the interpreter is more reasonnable.

There are 10 kinds of people : those who know binary, and those who don't.

Aminiel's Website

Quote Post 2

Thumbs up

Reply by CAE_Jones 2014-11-14 02:00:41

  • Registered: 2010-11-07
  • Posts: 8,471
  • User Karma: 692

1) "compile once, run everywhere" will sound great, until you actually try to distribute something and discover that it's pretty much completely false. (But if you find a way around this, please let me know!)
2) Java sound is, as Aminiel said, kinda problematic. It was weak-but-workable 10 years ago, though emphasis on "weak". With the rise of 64bit, the available mixers are getting less and less maintenance. If you read the history of Java sound backward, you get basic stationary single-sound playing, then support for pan and volume, then support for pitch-bending and reverb. (You know, I'm noticing a trend, here.)
2.3) If you can error-proof these, go ahead and play with them. I took an example sound player and modified it until I had something I could use.
SoundPlayer (The original came with a swing application for controlling the sounds, but I removed it for the sake of games.)
SoundBuffer (vaguely like BGT's sound_pool, but it has no concept of a listener.)
sound2player (basically the same as SoundPlayer, but it tries harder to make adjusting pitch available.)
3) I can't comment on JOAL or FMOD, other than to say there exist games in Java that use them, and I've never had the patience to get them working.

Still, it's worth trying. The emphasis on object-oriented programming and events is helpful most everywhere, and if you try to develop a game you'll inevitably learn something useful that might generalize to other platforms.
(An example of slow processes in java: gradient paints with alpha values. Not relevant if you aren't doing graphics.)

看過來!
"If you want utopia but reality gives you Lovecraft, you don't give up, you carve your utopia out of the corpses of dead gods."
MaxAngor wrote:
    George... Don't do that.

Quote Post 3

Thumbs up

Reply by Victorious 2014-11-14 05:08:04

  • Registered: 2010-11-08
  • Posts: 1,125
  • User Karma: 28

Yeah, i would definitely want to use 3d and such in sounds, so it looks like java for now might not be the best choice. Maybe if the 'compile once, run everywhere' isn't that true in practice, i would be better off just using c++, c# or something closer to c, as i've grown pretty comfortable with it.

Quote Post 4

Thumbs up

Reply by camlorn 2014-11-14 20:08:33

  • camlorn
  • You have defeated this forum and won a custom rank
  • Offline
  • From: Seattle
  • Registered: 2013-04-08
  • Posts: 10,801
  • User Karma: 2,083

Well, everything being said here is true.  To provide a little bit of hope, though, lwjgl provides OpenAL bindings.  Mind you, depending on how that communicates errors, you're either running up against checked exceptions (huge boilerplate blocks) or you're writing it as C (checking return values everywhere)...  Lwjgl does give everything needed, it's just not exactly fun and it's really, really monolithic.  Also, compile once run anywhere is never, ever true except for really small toy examples--in the real world you end up with a lot of platform specific code anyway.
For a lot of processing-intensive stuff, Java provides accelerated libraries--I'm specifically thinking of nio and some of the very very new parallel collections libraries.  But this doesn't impact on an audiogame one way or another, and if you're doing this kind of stuff you should be looking into OpenGL anyway.

My Blog
Twitter: @ajhicks1992

camlorn's Website

Quote Post 5

Thumbs up

Reply by Aminiel 2014-11-16 10:10:42

  • From: Switzerland
  • Registered: 2008-12-24
  • Posts: 638
  • User Karma: 54

If still interested, you might have a look at my audio library based on JavaSound
http://quentinc.net/quentincsoundapi

but as already said, it's quite limited, and really not as fast as other libraries (the minimum buffer size I was able to work with was 75ms, which is quite a lot compared to the more usual 20-30ms)

There are 10 kinds of people : those who know binary, and those who don't.

Aminiel's Website

Quote Post 6

Thumbs up

Reply by Ethin 2014-11-20 05:28:32

  • Ethin
  • Generous angel
  • Offline
  • Registered: 2010-04-21
  • Posts: 8,178
  • User Karma: 1,096

I think that you guys are forgetting something: You can use the 'native' keyword to define a native type. So yes, you can develop an audiogame in Java. You'll need to know a little C/C++, though, as Java doesn't have all of the... er... proper librariesfor it.

"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question."    — Charles Babbage.
My Github

Quote Post 7

Thumbs up

Reply by camlorn 2014-11-20 17:11:15

  • camlorn
  • You have defeated this forum and won a custom rank
  • Offline
  • From: Seattle
  • Registered: 2013-04-08
  • Posts: 10,801
  • User Karma: 2,083

That's not as easy as you think.  Every single programming language ever has an equivalent of it; Java's is the worst I have seen anywhere.  Java is a case study in how *not* to do it though, in fairness, this may have a lot to do with java's age.
The native keyword is an indication to the compiler of Java that a specific method or type is implemented in C, using JNI.  This simply causes the java compilers to go look for it in C/C++.  To actually do it, you need to implement a C++ library with the type, and then implement a second C++ library that uses the special Java C API to re-wrap it up into a nice Java class.  You can maybe do them as one, but then you've wasted a bunch of effort because your C library is now Java-only forever.  This involves a bunch of hand-coded lookups against the Java VM and has a lot of pain points--it's the responsibility of the C/C+ side to make sure that Java objects stay alive, for one.  As soon as you do this, your compile once is gone for good.  You're now either distributing platform-specific jars or compiling the library on multiple machines and doing a frankensteinish combination that loads the appropriate library version at runtime and packages them all.  LWJGL does the latter, I think.  There's JNA, if you must, but you still lose the compile once thing and JNA says it's an order of magnitude slower.  I've been looking into how to do this for Libaudioverse.  Ctypes and similar do not frighten me.  JNI gives me a headache every time I see the word, and JNA  is out of the question because I want Android.
In most languages, you convert the types in the language doing the bindings.  In java, you have to do all the conversions and whatever else in C, so have fun.
By the time you know C/C++ well enough to do this, you might as well just use C/C++.  It's also not the specific problem under discussion here: Java is too slow to do graphics in without using something like LWJGL, but the real killer is that java fails to deliver any good audio libraries.

My Blog
Twitter: @ajhicks1992

camlorn's Website

Quote Post 8

Thumbs up