Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (715)
Games in Android Showcase (214)
games submitted by our members
Games in WIP (788)
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 ... 40
1  Discussions / General Discussions / Re: C++/Java Engine without GC in graphics on: 2017-03-27 13:14:53
Well, I can halve my frame rate just by turning on G1GC...

Anyone can halve the rate of anything by turning on G1GC  persecutioncomplex   Grin

Seriously, I hope they improve things a lot by the time Java 9 is out the door.
2  Discussions / General Discussions / Re: C++/Java Engine without GC in graphics on: 2017-03-27 10:18:24
You won't gain any immediate advantage just because you use C/C++.

Well, you'll probably gain an immediate disadvantage!  Wink  Yes, well written C/C++ might outperform Java, but you've got to get there first - it's easy to write C/C++ that underperforms Java.

And GC is probably not as much of an issue as you think it is.

As for "script" in Java ...  Undecided
3  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-25 12:46:46
What is a ServiceLoader? How would that work with my enums? What kind of advantages are there here?

It's the standard method built into the JDK for an abstraction to find an implementation without having any dependency on it. eg

What I mean is that you build an initialization step into the abstraction API that looks up implementations at runtime using ServiceLoader. This usually involves an implementation of a provider class.  That in itself isn't specific to your enums.  As part of that initialization the abstracted API (eg. code in the enum or same package) queries the provider implementation for each int value and caches it in the required enums.  The implementations do not have to initialize the enums themselves, or know anything about what mechanism you're using to cache the constant mapping.  You manage the mechanism, initialization order, etc. in one place rather than many.

The code @Archive posted where each backend has to call back into each enum, know all the possible values, do things in the right order, etc. becomes tiresome quickly the more the API expands and the more backends you have.
4  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-24 18:37:35
If you're going to have the variables inside the enums for speed, I'd use ServiceLoader to lookup the required implementation at runtime and request the underlying values from it, rather than have the implementation have to configure the enums itself - that's ... yuck!  persecutioncomplex
5  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-24 15:06:44
Because evidently an EnumMap is just a wrapper around an array indexed with ordinal() anyway, and using EnumMap has too much overhead, bad cache coherency and will need autoboxing of the integer constants to fit them in.

That was my point, that you were reinventing it without knowing whether it's actually a bottleneck.  True, if you're mapping to int you've got the unboxing.  Where's the bad cache coherency come from in there though?  From the Integer?  I guess you need an EnumIntMap then!   Smiley  Few around.
6  Game Development / Game Play & Game Design / Re: Graphics Backend Abstraction on: 2017-03-24 11:34:18
My proposed solution would be to have the enum--->constant mapping in the backends instead. A hashmap is gonna be way too slow, but a simple array indexed by ordinal() could work.

er ... EnumMap!

OK, so I need to write more text  Roll Eyes  Why would you use an array indexed by ordinal() over an EnumMap?
7  Game Development / Newbie & Debugging Questions / Re: JavaFX audio not working properly? on: 2017-03-21 19:36:21
Well, this comment is amusing - wonder if that's still the up-to-date source?!  Roll Eyes  Good to hear AudioClip in JavaFX is just as broken as the JavaSound one then.
8  Game Development / Performance Tuning / Re: ArrayList$Itr and Escape Analysis on: 2017-03-06 13:57:03
Are you in a position to try / use Java Mission Control?  According to various things I've read, including the article you linked to, this can analyse without switching off escape analysis.
9  Discussions / General Discussions / Re: Programmer jokes on: 2017-02-05 18:50:51
Psssssst! beat ya!  Grin
10  Discussions / General Discussions / Re: Programmer jokes on: 2017-02-05 18:49:32
@DarkCart or from the other side  Grin ...

<a href=";hl=en_US&amp;start=" target="_blank">;hl=en_US&amp;start=</a>
11  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Advantages of Ant? on: 2017-01-29 13:09:53
IME having external dependencies in a build is a bit like building your castle on sand. The build must always succeed. Discuss.
This is actually only a mild problem with maven and gradle. If you want to see this problem in an apocalyptic scope, use npm Shocked

Yes, experienced the npm hell!  Angry From what I remember you have to specify an exact version for dependencies to build against in Maven so that every build is reproducible.  That is how to handle external dependencies IMO.  The problem @princec outlines should not be possible with Maven.

 ... oh, and while I maintain a number of libraries that use Maven for build, my main project uses Ant for reasons similar to @gouessej and I really can't be bothered trying to find workarounds. Make of that what you will.  Grin
12  Game Development / Newbie & Debugging Questions / Re: LibGdx, Eclipse and Gradle about hotSwap on: 2017-01-19 14:19:32
When you attach a debugger to your application (in your case Eclipse is the debugger client), the JPDA client can issue a request (over the JDWP / Java Debug Write Protocol) to redefine a class

More specifically, it allows you to redefine the code of a method.  You cannot change the structure of a class - add fields / methods, change method arguments, etc.

Oracle's HotSpot and OpenJDK support it)

Well, as they're one and the same thing ...  Grin  usually
13  Game Development / Newbie & Debugging Questions / Re: getting rid of "instanceof" on: 2017-01-15 12:12:00
This solved the "instanceof" dilemma immediately. Now when I process a collision it is more like this:

public void visit(BallStateNormal visitable) {
      Ball ball = (Ball) visitable.getMob();

hmm .. removing the instanceof and having a blind cast is not improving things!  Doing instanceof -> cast, using visitors, pattern matching or heterogenous containers are all about filtering a collection of entities at runtime for those that are a / have a particular capability.  If you have a blind cast like that you either know at compile time the type returned, in which case that's what the method should return, or you're making an assumption that is overriding compile time checks and will eventually blow up on you at runtime.

@Abuse may be right that generics are the way to go here.  Although your concrete subclasses probably don't want to be generic or you're likely to end up needing to know genetic types at runtime (a PITA!).  So, something along the lines perhaps of BallStateNormal extends AbstractMobState<Ball>

However, also don't forget that overridden methods in Java can return a more specific subtype, so visitable.getMob() on BallStateNormal could return Ball already without generics.
14  Discussions / Suggestions / Re: Add a link to the embedded youtube video on: 2017-01-13 17:57:07
The YouTube embeds seem to work fine for me without Flash at all?!  HTML5 player in Chromium on Ubuntu.
15  Game Development / Newbie & Debugging Questions / Re: getting rid of "instanceof" on: 2017-01-13 12:16:54
@cylab - I use that "pattern" a lot, but then it's basically the same as the Lookup mechanism in the NetBeans platform.  Not sure if it's the fastest approach, but it's definitely one of the nicer ones.  Smiley

Incidentally, getHandler() could also return Optional to not require the supports() method, or you could even pass a consumer into a utility method on entity that does that for you. Hey, I like keeping the logic code succinct and less error prone.  Grin 

entities.forEach(e -> e.getHandler(PoisonGasEffect.class).ifPresent(h -> h.onPoison(1)));

entities.forEach(e ->  e.with(PoisonGasEffect.class, h -> h.onPoison(1)));
16  Game Development / Newbie & Debugging Questions / Re: getting rid of "instanceof" on: 2017-01-12 16:45:42
I don't get the "breaking encapsulation" part here.

Well, from GoF -

Visitor's approach assumes that the ConcreteElement interface is powerful enough to let visitors do their job. As a result, the pattern often forces you to provide public operations that access an element's internal state, which may compromise its encapsulation.

In general of your examples I prefer the behaviour in the entities (your last example), but they all have their places. Also, instanceof is not likely to be the slowest - enum would probably be slower (have seen a benchmark of that somewhere). Incidentally, the pattern matching style approach to your instanceof example could be something along the lines of -

entities.forEach(e -> when(e)
        .is(Monster.class, m -> m.kill())
        .is(Player.class, this::updatePlayer);
17  Game Development / Newbie & Debugging Questions / Re: getting rid of "instanceof" on: 2017-01-12 13:03:18
I agree with @princec. The code linked to by @nsigma is nothing but instanceof-in-disguise wrapped in Java 8 to make it less intelligible.

But done in a less verbose, safer and compile-time-checkable way!  It's getting closer to smart casts in Kotlin (eg.

I generally agree with the bulk of what you've said by the way - this is always for edge cases.
18  Game Development / Newbie & Debugging Questions / Re: getting rid of "instanceof" on: 2017-01-12 12:51:58
Jeez, that's among the most awful code I've ever had to look upon Sad

Welcome to our functional future!  Grin

4. You want to write (and hence maintain) the bare minimum of actual code

1-3 may be right (3 might depend on number of types), but 4?!  That's why I hate it.

IMO casting in OOP is one of the strongest bad smells in code, and instanceof is essentially a cast.

So is breaking encapsulation, which is why I'd shy away from both whenever possible.
19  Game Development / Newbie & Debugging Questions / Re: getting rid of "instanceof" on: 2017-01-12 12:12:29
Seriously, what is wrong with visitor? It's fast, it works, it catches anything awry at compile time, and with default methods on interfaces it's not even ugly any more - what's not to like?

A lot!  It breaks abstraction, adds a load of code and ends up with logic in the wrong (or less convenient) place.  instanceof and the visitor pattern are both workarounds to Java's lack of double-dispatch, the latter originating from C++ IIRC.  Needing to use either can therefore be a sign that your code is structured wrongly.  That doesn't mean that you should never use either!  A few instanceof statements may then actually perform equally well or better than the visitor pattern, not use 10x the code, and keep your logic in the right place.

I agree with both @CoDi^R and @philfrei - look at code restructuring and look at enums before using either instanceof or the visitor pattern.  But also don't listen to anyone saying that any use of instanceof is a code smell.

I like the simple (or less simple) approaches to pattern matching over the visitor pattern, because it doesn't require changes to the target classes and keeps the logic together.
20  Game Development / Newbie & Debugging Questions / Re: getting rid of "instanceof" on: 2017-01-11 22:54:41
IMO if instanceof is a wart, the visitor pattern is a tumour.

A) don't be overly paranoid about instanceof Some usage isn't bad. Working around the lack of multiple dispatch in Java by adding a load of boilerplate is often not worth it.

B) Java 8 is a brave new world. Check out approaches to functional pattern matching.
21  Games Center / WIP games, tools & toy projects / Re: Hexara rewrite with Java 8 & JavaFX on: 2017-01-04 10:56:42
Don't get confused! AnimationTimers are not threads. They're all invoked on the JavaFX application thread by the JavaFX pulse.

Haha, just made almost identical response on Phil's other topic - heard it from two of us now!  Grin
22  Java Game APIs & Engines / JavaFX / Re: [SOLVED] problem Adding/removing Nodes on: 2017-01-04 10:54:24
Is the animation timer actually on the JavaFX Application thread? It is a separate thread, it seems to me.

No, the callbacks are on the JavaFX Application thread, same as the Swing Timer actions are called on the EDT.  That's the whole point of these classes.

You might be better using Platform.invokeLater(..) from your audio thread.

Don't assume all the places that require updates on the FX thread will throw exceptions if you're not on it.  This is unusual, as it forces the cost of checking what thread you're on for all usage - I assume there's a good reason why some of these methods do that, perhaps due to native code interactions.
23  Java Game APIs & Engines / JavaFX / Re: [SOLVED] problem Adding/removing Nodes on: 2017-01-02 16:18:09
Fingers crossed, maybe it's just a situation where property changes might not propagate in the order made or something minor, rather than an outright crash. I suspect that JavaFX is more robust than Swing.

Really don't assume that!  You're doing something the library is specifically designed not to support - robustness is therefore irrelevant.

From the Node JavaDoc -

Node objects may be constructed and modified on any thread as long they are not yet attached to a Scene. An application must attach nodes to a Scene, and modify nodes that are already attached to a Scene, on the JavaFX Application Thread.

Note this is different to Swing where you're not even supposed to construct or modify an unattached component off the EDT.

What you're doing looks like premature optimization, and one that probably isn't an optimization.  Wink
24  Java Game APIs & Engines / JavaFX / Re: problem Adding/removing Nodes on: 2017-01-02 14:55:28
I am still figuring out what is or isn't "touching" the FX Application thread, to use your terms.

There is a lot that can be done with JavaFX controls off of the FX thread. (And should be, to avoid clogging the thread and slowing down the app.) I can change properties from an external thread. In the opening for Hexara that I'm recoding, an animation thread is handling an opacity fade. The error message came up only when trying to add or remove a node to the current scene.

I didn't say touching the FX Application thread, I said touching JavaFX on another thread.  By which I mean pretty much anything!  Neither JavaFX or Swing are thread-safe, which means you should never create any object or call any method (of a JavaFX/Swing class) from anything other than the application thread / EDT unless it's specifically marked as thread-safe.  What you're doing may or may not work, for now, with this version of Java, with your OS, on your machine.
25  Java Game APIs & Engines / JavaFX / Re: problem Adding/removing Nodes on: 2017-01-02 14:03:51
The FX Application thread seems to be the JavaFX equivalent of the EDT on Swing. If this error crops up, the solution is to schedule the code to run on the FX Application thread. This can be done as follows:

Surely you mean never, ever, ever touch JavaFX off the FX Application thread, the same as never, ever, ever touch Swing off the EDT?!  Pointing
26  Games Center / WIP games, tools & toy projects / Re: Praxis LIVE v3 - hybrid visual IDE for creative coding on: 2016-11-15 19:15:53
So, Praxis LIVE v3.0.0 is available - well, actually has been available for a few weeks now but I forgot to update this ...  persecutioncomplex

Downloads from, source code on GitHub.

Lots of changes have been made under the hood, including updating the embedded compiler to Java 8 with some new lambda goodness in the API, performance improvements in the OpenGL pipeline, updating GStreamer video support to 1.x, and revising all the audio components to be stereo and live-codeable.  Distributed hubs support has been improved with the ability to run the compiler on another process / machine, and a lightweight HTTP file server added for asset sharing.  And a new internal type for binary data (needed for bytecode) makes it easier to pass complex data around (eg. FFT data - see video).

See the full list of changes at

Since the release I wrote a blog post about Cyberphysical coding on the JVM, which also talks about some more general uses of live real-time coding and links to my ICLC paper mentioned above.  If this interests you too, say hi!  Smiley

I'll finish with some Funky Origami - here's a video rendering of one pass through one of the new examples using some of those new features, demonstrating generative audio and controlling a simple 3D shape with FFT data.

<a href=";hl=en_US&amp;start=" target="_blank">;hl=en_US&amp;start=</a>
27  Java Game APIs & Engines / Java Sound & OpenAL / Re: Should sound be on its own thread? on: 2016-10-31 11:58:46
@nsigma: If it is not too much trouble, could you demonstrate an example of the code in TinySound that tests if a sound or music cue has finished? I didn't know this could be done.

This week ... unlikely ... sorry  persecutioncomplex However, the TinySound Music interface has a done() method. I'm assuming that works right!  Grin

In my audio library, the equivalent Listener is frame-accurate. There is also a frame accurate event-scheduler.

The listener is good as a low-level mechanism, but as a library API it's somewhat problematic.  To work it requires that the listener is called in the audio thread, is lock-free, and perhaps forces certain state not to be messed with.  It's not ideal for the end user.  OTOH, a rich event scheduling API where the library user can pass in commands via a lock-free queue is generally a better approach for those unlike us who don't want to get deep into the nitty gritty.
28  Java Game APIs & Engines / Java Sound & OpenAL / Re: Should sound be on its own thread? on: 2016-10-30 23:11:59
This isn't about abandoning Java's audio - the library examples I gave are all deliberately things that build on JavaSound and do this properly.  I don't see a problem with handling your scenario in any of them - it's a pretty basic ask.  They're also going to do it with much better accuracy and performance.  Seriously, this is not a reason to use Clip.

With TinySound, you could also just check in your game loop whether the sound (actually Music!) has finished and retrigger it if required (eg. count greater than 0).  This won't offer sample accuracy - given that line listeners on a Clip aren't either and bring in a massive amount of overhead, it's still going to work a lot better! (EDIT - you realise that for each line listener call the output to the soundcard has been stopped and needs restarting? That's not cheap!)

I also think that OpenAL supports queuing of sounds in this way.  Never used it though, so I'm not the right person to answer.
29  Java Game APIs & Engines / Java Sound & OpenAL / Re: Should sound be on its own thread? on: 2016-10-30 12:08:06
No need to apologize @philfrei - just amused by the contradiction in your post, which does highlight quite a few ways that Clip is not the answer to this problem - is not designed for this.

We simply should not be advising people to use Clip in this case, or trying to suggest complicated workarounds that could easily break on another system.  There's no fundamental issue with JavaSound, but ill-advised usage like this just leads to a world of pain.

If the OP wishes to stick with a pure-Java solution then they need to look at one of the libraries designed for this (or write their own).  TinySound is one option, but there are others.  Minim is probably worth a look (which was written for Processing but will work outside it), or Beads, or JASS, or JSyn, or ...

... one day I may actually get around to making a single library out of the audio code in Praxis LIVE  persecutioncomplex
30  Java Game APIs & Engines / Java Sound & OpenAL / Re: Should sound be on its own thread? on: 2016-10-29 18:47:27
So, Phil, one line to disagree with something I didn't quite say, followed by four paragraphs that pretty much agree with what I said!  Tongue

I didn't say that Clip is not designed to be played more than once, but that they're badly specified for rapid, overlapping or synchronized sounds.  This is because the API is specified as extending DataLine rather than something that writes to a DataLine.  Since the (positive) move to direct audio devices, this means that it punts responsibility to the OS for mixing on AFAIK all implementations, rather than doing it internally.  Also, from OpenJDK source code it looks like each Clip uses a separate underlying Thread.  All this makes sense for the odd business use case for sound, but explains why application level mixing is required to get good performance for more complex uses in games, music, etc.

OpenAL-Soft uses an internal mixer to write to a single playback "line" as required.  It would be possible to write a pure-Java application that did everything OpenAL-Soft does using a JavaSound line, but not using Clip.

Pages: [1] 2 3 ... 40
CopyableCougar4 (186 views)
2017-03-24 15:39:42

theagentd (168 views)
2017-03-24 15:32:08

Rule (225 views)
2017-03-19 12:43:22

Rule (210 views)
2017-03-19 12:42:17

Rule (215 views)
2017-03-19 12:36:21

theagentd (233 views)
2017-03-16 05:07:07

theagentd (230 views)
2017-03-15 22:37:06

theagentd (170 views)
2017-03-15 22:32:18

theagentd (164 views)
2017-03-15 22:31:11

ral0r2 (163 views)
2017-03-03 11:52:41
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51 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!