Hi !
Featured games (87)
games approved by the League of Dukes
Games in Showcase (671)
Games in Android Showcase (194)
games submitted by our members
Games in WIP (727)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 38
1  Game Development / Newbie & Debugging Questions / Re: Sound on Debian Jessie Linux on: 2016-04-26 20:26:16
because the sound works when no other programs are open.

OK, that means it's reverting to using the direct ALSA device, which is exclusive - only one application can access this at a time.  PulseAudio should be the default audio device.  Which means either -

a) OpenJDK is using the direct ALSA device for Applet audio output (really, you shouldn't be using these methods for audio - use JavaSound or check out TinySound if you want something simpler on top).

or, b) someone has changed the configuration of OpenJDK on that machine not to use PulseAudio.
2  Game Development / Newbie & Debugging Questions / Re: Sound on Debian Jessie Linux on: 2016-04-26 15:59:37
Just to double check, because I'm not sure what you mean when you say you are using AWT's sound. AFAIK, there is no play() method for audio in the AWT library.

There's one in Applet.  I think it might be using JavaSound under the covers anyway, but doing anything with Applet seems pointless in this day and age.  Grin

... hmmm, that JavaDoc says nothing happens if the audio clip cannot be found!  Are you sure you're finding the URL of the file correctly?
3  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-04-26 15:48:06
I switched from LWJGL (2) in Praxis LIVE v1 to JOGL in Praxis LIVE v2, because I switched rendering library from (a fork of) libGDX to Processing.  In general I'd suggest the library support around whichever binding you choose is more important than the binding itself.

I'd also say I'm becoming more in favour of JOGL's non-static approach <ducks for cover  Grin >.  This is worth a read in that context -  I made similar choices for similar reasons in bindings for a native audio library that I maintain.

4  Game Development / Newbie & Debugging Questions / Re: Sound on Debian Jessie Linux on: 2016-04-24 15:10:32
I'm using the newest Java update ...

Oracle or OpenJDK?  IIRC the Oracle one doesn't include PulseAudio support.

and just playing audio with in AWT.

Why would you do that?
5  Discussions / Miscellaneous Topics / Re: lambdas rant on: 2016-04-11 09:07:42
I'm using lambdas only where readability is more important than performance

Well, if that's the case in practice, they've failed!  (not used them yet - still targeting JDK 7 compatibility  persecutioncomplex )

Quote from: roquen
The last I heard JVM lowering invokedynamic was much more expensive than they thought it would be.

But that's still only a one time hit?
6  Discussions / General Discussions / Re: Core Java Syntax on: 2016-03-20 10:50:42
I'm not a fan of fluent style stuff myself

You must really hate Java 8 then?!  Tongue

Have to say I really am a fan of this if done well.  To me it's the opposite issue to above - reducing verbosity increasing legibility.  And it's not like you have to use it anyway.

Mind you, the fluent stuff (or any method call) on the end of a constructor does look daft.  To each his own.  Wink
7  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-18 12:09:23
@princec - ah, good point!  I was more wondering what the runtime performance differences might be between the OpenGL ES headless mode and the full OpenGL X11 one (having read recently that it's now in public beta)  Wasn't thinking about boot time.
8  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-18 11:18:59
I am eagerly awaiting LWJGL on the Pi (headless?)

Any idea what the (longer term) benefit would be to having it headless?
9  Game Development / Newbie & Debugging Questions / Re: Video playing in game on: 2016-03-17 13:02:23
Like @Cero I'm not personally interested in Android as a platform.  However, there is a GStreamer build for Android, and JNA should also work, so in theory you should be able to get it to work with a bit of effort.

There is also a tutorial for using GStreamer on Android via NDK, but then you have to write a bit of C code too -
10  Discussions / General Discussions / Re: Core Java Syntax on: 2016-03-17 12:50:33
That will not work because the compiler does not know what type var would be if you use it as method parameter.

I know. I was being sarcastic!  Grin
11  Games Center / WIP games, tools & toy projects / Re: 3D audio test using JavaFX and procedural java sound on: 2016-03-17 09:17:11
As far as I know, there's no way to package a game with a Max patch without it turning into an embarrassing mess of duct tape, and anyway, I can't see why any sane human would want to. Max is fun and easy, but Java->OSC->Max isn't exactly a high-performance solution.

I'm assuming Max doesn't have an equivalent to libPD then?  That might be an alternative to look at based around the open-source "equivalent", Pure Data.

There's no reason in principle the Java->OSC->[something] approach couldn't be high-performance.  OSC was originally designed for real-time audio control.  Lots of systems use it to communicate between audio process and front-end (incl. Supercollider as you said).  In fact, I'm using a Java->OSC->Java mechanism to offload Java audio into a separate process and this performs better than using a single VM because the audio process can be tailored to have low memory heap, minimal garbage collection, etc.
12  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-03-16 16:58:38
The only thing time implicit casts would be okay would be inside an if(instanceof)-block. Frankly, why not just update the type of the object tested if it can be proven to be that type within a block?

if(x instanceof String){
    //Inside here x is a String.

Try reading the example I posted earlier and the link to the Project Coin mailing list archives.  One reason your suggestion was rejected relates to overloaded methods -

void doSomething(Object s) {}

void doSomething(String s) {}


if (x instanceof String) {
    //Inside here x is a String.
  doSomething(x); // oops, we've changed behaviour!

13  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-03-16 15:18:27
then I am already asserting that always returns a String even it it is declared to return an Object

You're asserting it for certain circumstances / certain state of your project.  If that's always the case and is your code, rewrite!  Otherwise, that's not the same assertion.

My point is really the opposite - in line 2 you're not asserting anything.  It's equally likely that people write that code as a mistake.  Now, the compiler will flag that as an error.

Quote from: CommanderKeith
Isn't widespread use of instanceof seen as an anti-pattern?

I'm generally of the opinion that single use of instanceof or casting (eg. not a chain of if statements) is fine on occasion and better than the convoluted crap people sometimes write just because they've heard they shouldn't use it!   persecutioncomplex  It's a useful workaround to Java not having double dispatch.
14  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-03-16 14:57:49
String x = (String);
String x =;

And as @KaiHH says, this has nothing to do with what the compiler can figure out and everything to do with what a human can figure out!  Looking at that code, line 2 tells me that always returns a String, line 1 says it might not.  These are semantically different.  I think the number of people who'll code that pattern by mistake will outnumber the number who want it!
15  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-03-16 14:40:04
Thirdly, the diamond operator was previously invalid syntax, not just invalid code?  I think some of the Project Coin proposals were rejected on that basis.

Project Coin had a similar proposal to JEP 286 which used final.  In some ways that makes a lot more sense to me - if you want a variable you can assign to later you should be explicit about the type.
16  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-03-16 11:05:02
Actually, Project Coin proposal moved on to

if instanceof (String obj) {
  String s = obj.trim();

which is more like I remember.  Also some examples of why using existing syntax (as @Riven) was problematic.

Anyone interested -
17  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-03-16 10:44:36
if(obj instanceof String) {
   String str = (String)obj; // seriously? I have to cast here?
Maybe using 'var' here will finally resolve this 2 decade old annoyance Smiley

Think I found the instanceof thing I mentioned previously from the Project Coin list, although it seems more verbose than I remember.

switch (obj) instanceof {
  case String:
    // obj is now String
    obj = obj.trim();

Mind you, using switch suggests you'd have a chain of options, which is a real code smell!  Undecided
18  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-03-16 09:55:12
Just yesterday I said java would never consider type inference.

Just yesterday, if you'd bothered to follow the link in my comment before responding you'd have found the JEP!  Tongue

I think this whole proposal is horrible - it's a needless reduction in verbosity which really reduces legibility.  @noctarius, thanks for the SurveyMonkey link, I've registered my dislike.  And, yes, I'm an old fuddy-duddy! Smiley

@princec - interesting you mention generics - I compared this to the diamond operator in my response, which I think is useful and reduces verbosity while maintaining intent.  Not sure about your implicit casting.  It's not the impossible casts that bother me, it's the unintended ones.  Mind you, I remember seeing an idea for an instanceof block that combined that with implicit casting - that would be better.
19  Game Development / Performance Tuning / Re: Full Screen Performance and Memory Consumption on: 2016-03-15 17:48:54
What you really need to do is, yes, draw to an offscreen buffer, but also reuse that buffer.

I see that no one picked up on the obvious error that you should never use a BufferedImage for this kind of offscreen buffer.  This should be a VolatileImage.  You should look at the difference in how the two are accelerated (hint, the way this is done nothing is!)
20  Game Development / Newbie & Debugging Questions / Re: Video playing in game on: 2016-03-14 17:18:42
Thanks a lot! What do you think, can it made Gradle compatible for easier building and deploying?

IIRC Gradle can use Maven repositories?  At least the gstreamer-java library (for GStreamer 0.10) is available via Maven, although that doesn't answer the native libraries, native library loader or Cero's OpenGL code.  gst1-java-core (GStreamer 1.x) isn't yet available via Maven repositories, but hopefully will be soon.  That native library loader should go up on GitHub too - it's been adapted through so many projects ? -> Processing -> Praxis LIVE -> Cero's.  At some point I'll set up a repository for it at

@Riven - I understand that you're still getting the bulk of the advantage of GPU decoding (in the same way we do currently given we don't yet have texture sharing), but it's still an inefficiency that can't be worked around in that scenario, and I'm less sure on the overhead - something tells me an outdated PC may be the worst way to measure it!  Wink  I did, incidentally, suggest the OP try YUNPM, as it's going to be far simpler to get started.  However, I also think it's worth being aware of the limitations up front - if you know you're going to hit them it's better than having to start again from scratch.

eg. It does actually look like you implemented seeking already.  However, it's implemented by destroying the FFMPEG process and starting again.  Something tells me that's going to struggle to meet @Cero's need for seamless looping?  Likewise, while I realise you implemented frame-skipping, I still maintain the opinion you might struggle with sync at times because you've got no easy way to drop frames from the head of the process.
21  Discussions / General Discussions / Re: Core Java Syntax on: 2016-03-14 16:47:56
Because I don't want to type float 5 times :/ nor double 3

I think you should re-read @Riven's answer!  Grin

Still, as much as I dislike the enhancement you're suggesting, I think I prefer it to local variable type inference.

var list = new ArrayList<String>();

Put the two together and we could have -

public void doSomething(var x, y, sx, sy) {}

Joy!  TL;DR what we have could be a lot worse - I'd rather have verbose and legible.
22  Game Development / Newbie & Debugging Questions / Re: Video playing in game on: 2016-03-13 17:21:09
I am using gstreamer-java-1.6.jar

Which is actually a binding for the old GStreamer 0.10 series - don't get me started on the version mismatch!  Wink  The binding for GStreamer 1.x is gst1-java-core as linked above, although it's still in development.  Mind you, you'd have to replace all your native libraries too.
23  Game Development / Newbie & Debugging Questions / Re: Video playing in game on: 2016-03-13 17:07:41
You are turning vague handwaving into a real art.

Well, got to be good at something!  Grin

GPU decoding is handled by ffmpeg, regardless of the export-format, obviously, as it is GPU decoding.

But you're bringing it back into CPU memory, right?  I may be wrong, but it's not possible / easy to GPU decode directly into a texture because it would require texture sharing across process boundaries?  

What does he need beyond simple use cases anyway, he's trying to play a video in game (hence the topic), not writing a full fledged media player.

There are lots of interesting things that could be done with video in a game that aren't just about playing cut scenes - eg. "scratching" back and forth to create animated textures.
24  Game Development / Newbie & Debugging Questions / Re: Video playing in game on: 2016-03-13 15:59:54
Quote from: Cero
Only thing thats annoying is, when looping, for backgrounds and similar, I get like a 300ms or so stutter,

That's almost certainly a bug in your code.  Try the same video in Praxis LIVE and tell me if you see the same.  It looks like your code is stopping and restarting the pipeline when looping, which is not the way to do it!

Quote from: Cero
Pretty sure its GStreamerLibrary.init() which freezes without error.

Never seen that, but having taken over maintainership of the bindings for GStreamer 1.x I'd love to see a thread dump!  I'm aware of one rare deadlock scenario that needs fixing, which shouldn't be related to this unless you are running that init() code in multiple threads at the same time?  Could also be an issue with GStreamer 0.10 itself which is unsupported now.

Quote from: Riven
@OP: What holds you back giving YUNPM a try? ...It has never crashed or frozen, yet

There are pros and cons of running things out of process.  For the OP, I agree it's probably the easiest way to get started, for simple use cases anyway  Wink   Mind you, I guess no way of benefiting from GPU decoding using that model?
25  Game Development / Newbie & Debugging Questions / Re: Video playing in game on: 2016-03-13 10:43:57
I do have a gstreamer solution working under libgdx but it would be a lot of work getting it in there, especially with the native binaries. getting gdx video to work makes more sense

This may be easier these days given that there are official cross-platform binary downloads available for GStreamer 1.x, and much more of a focus on it being cross-platform.

The most interesting bit is not yet available in the Java bindings, though.  Andres from the Processing project is currently working to bind GStreamer's support for OpenGL textures, which will open up GPU video decoding direct to textures.  I'm awaiting a pull request with much anticipation!
26  Game Development / Newbie & Debugging Questions / Re: J8 @Repeatable with Generic on: 2016-03-09 11:18:31
Which compiler / IDE?
27  Discussions / General Discussions / Re: Comparing Rust and Java on: 2016-03-01 19:06:38
There's nothing about "the" JVM that says Java is just-in-time compiled. There are quite a few JVMs around these days. Some of them are JITted, some of them are AOT, some of them are just interpreted. The JVM specification specifies how things should behave, not how they should be implemented, and this seemingly trivial subtlety makes a surprising difference.

Ah, true, but not what I thought you were getting at - Java bytecode is (may be! persecutioncomplex ) JIT'ed, Java code itself isn't (usually! persecutioncomplex ).

Dang, you made me want to put caveats everywhere!  Wink
28  Discussions / General Discussions / Re: Recording movie files from Java on: 2016-02-27 18:43:10
Why? What for? D:
I hate to be that guy, that asks for why, but unless you are developing stuff that nsigma does ..

Good question!  Smiley In fact, I haven't implemented video rendering to file in my stuff so far either - the reason, because if you have the stuff on screen, and particularly if it's OpenGL / accelerated rendering, you'll likely get better performance from a screen capture software designed for gaming than you will from something internal (without a lot of work).
29  Discussions / General Discussions / Re: Recording movie files from Java on: 2016-02-27 11:04:21
GStreamer is absolutely horrible. Just use mencoder or VLC and be done i 5 min instead of having nothing but problems for days.

GStreamer has a learning curve!  Tongue  Encoding a sequence of images is not always the best option for this, though - depends what the OP wants to do.  Mind you, another option coming from what you said - VLCJ probably allows you to feed a pipeline directly with image data too (

btw, while you're right that Java has never developed a proper standard lib for writing video files, you know that the new standard lib for playing them is based on GStreamer, right?  persecutioncomplex
30  Discussions / General Discussions / Re: Recording movie files from Java on: 2016-02-26 10:28:32
GStreamer can do this, but you'll have to get down and dirty with pipeline configuration -  There are some Processing examples for recording AVI using GStreamer 0.10 - I'm not sure if the GStreamer 1.x bindings will work for this yet (and if not it's my issue to fix it  persecutioncomplex )

One project that might be worth looking at is  It'll give you some idea of various video libraries that are available, and it does have an example for recording to file (not tried it!)

I've also seen code that claims to write an MJPEG AVI in pure Java - check out the AVIWriter class on this page -
Pages: [1] 2 3 ... 38
IanParcs (44 views)
2016-04-18 14:18:53

KaiHH (43 views)
2016-04-18 08:35:41

KaiHH (74 views)
2016-04-15 12:43:58

theagentd (75 views)
2016-04-14 02:16:17

theagentd (89 views)
2016-04-14 02:15:43

IanParcs (103 views)
2016-04-12 03:51:16

IanParcs (46 views)
2016-04-12 03:50:03

IanParcs (42 views)
2016-04-12 03:49:54

IanParcs (37 views)
2016-04-12 03:49:52

IanParcs (47 views)
2016-04-12 03:49:52
Website offering 3D Models specifically for games for free
by vusman
2016-04-29 12:56:17

List of Learning Resources
by SilverTiger
2016-02-05 09:39:47

List of Learning Resources
by SilverTiger
2016-02-05 09:38:38

List of Learning Resources
by SilverTiger
2016-02-05 09:35:50

Rendering resources
by Roquen
2015-11-13 14:37:59

Rendering resources
by Roquen
2015-11-13 14:36:58

Math: Resources
by Roquen
2015-10-22 07:46:10

Networking Resources
by Roquen
2015-10-16 07:12:30 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!