Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (707)
Games in Android Showcase (206)
games submitted by our members
Games in WIP (781)
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  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:

1  
2  
3  
4  
5  
public void visit(BallStateNormal visitable) {
      Ball ball = (Ball) visitable.getMob();
      brick.bounceBall(ball);
                //
}


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.
2  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.
3  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 

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

entities.forEach(e ->  e.with(PoisonGasEffect.class, h -> h.onPoison(1)));
4  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 -

Quote
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 -

1  
2  
3  
entities.forEach(e -> when(e)
        .is(Monster.class, m -> m.kill())
        .is(Player.class, this::updatePlayer);
5  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. https://kotlinlang.org/docs/reference/typecasts.html)

I generally agree with the bulk of what you've said by the way - this is always for edge cases.
6  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.
7  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.
8  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.
9  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
10  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.
11  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 -

Quote
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
12  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.
13  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
14  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 www.praxislive.org, 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 http://praxis-live.readthedocs.io/en/latest/releases/

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="http://www.youtube.com/v/VBaY2_XXlaI?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/VBaY2_XXlaI?version=3&amp;hl=en_US&amp;start=</a>
15  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.
16  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.
17  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
18  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.

19  Java Game APIs & Engines / Java Sound & OpenAL / Re: Should sound be on its own thread? on: 2016-10-28 16:40:24
Never use Clip for this purpose.  It's not really designed for it.  Clip opens a line to the soundcard every time it's used.  For good performance in a game you want to open a line once and mix sounds to it as needed.  This is low level stuff - you may want to have a look at a library that does software mixing for JavaSound, such as TinySound, instead.
20  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-10-25 11:22:10
AMEN $ Mother Function : having some fun doing a live-coded single function demolition of the most ubiquitous sample in modern music (takes a little while to get going)

This is why they added lambdas to Java 8, right?!  persecutioncomplex  Grin

<a href="http://www.youtube.com/v/qTQoE5UHgP8?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/qTQoE5UHgP8?version=3&amp;hl=en_US&amp;start=</a>
21  Game Development / Shared Code / Re: Midi and Hertz conversions on: 2016-10-07 23:42:32
I'm using the code as @KaiHH posted.  While it might be possible to optimize it, I highly doubt it's worth it.

The class with this in also has some code I ported from Frinika that converts note names to MIDI number to feed into this.  That might be useful for what you're doing?

https://github.com/praxis-live/praxis/blob/master/praxis.audio.code/src/net/neilcsmith/praxis/audio/code/NoteUtils.java
22  Games Center / WIP games, tools & toy projects / Re: Praxis LIVE v3 - hybrid visual IDE for creative coding on: 2016-10-06 14:21:14


A release candidate of Praxis LIVE v3 is now available, with lots of exciting new features.  It's feature complete, but not fully tested / documented yet.

I'm currently on my way to Canada for the International Conference on Live Coding, where I'll be presenting a paper and demo using Praxis LIVE.

The full release will be done ASAP when I get back (yes, ran out of time!  Grin ).  In the meantime ...

v3.0.0-rc1 download - https://github.com/praxis-live/praxis-live/releases
v3 key changes - https://github.com/praxis-live/support/issues/34
23  Game Development / Articles & tutorials / Re: GPU blur performance analysis on: 2016-10-04 17:14:16
Really interesting!  Are you happy to share the benchmark code?
24  Java Game APIs & Engines / OpenGL Development / Re: Gaussian Blur Blobs? on: 2016-10-04 13:40:35
It's an issue with the alpha I bet. Don't blur the alpha.

Or better, use premultiplied alpha textures. Blurring will never work correctly on images with alpha without it.
25  Discussions / General Discussions / Re: Comparison between 2 IDE's - Netbeans and Eclipse on: 2016-09-15 08:09:30
@nsigma
Hey you're up there with the big guns as an initial contributor, nice!
James Gosling (Liquid Robotics)
...
Neil C. Smith (PRAXIS Live)

Yeah, the company's not bad  Grin

... even if the capitalization leaves something to be desired!  Undecided
26  Discussions / General Discussions / Re: Comparison between 2 IDE's - Netbeans and Eclipse on: 2016-09-13 11:22:12
Interesting news on the NetBeans front -

https://wiki.apache.org/incubator/NetBeansProposal
27  Games Center / WIP games, tools & toy projects / Re: Praxis LIVE v2 - hybrid visual IDE for creative coding on: 2016-09-02 17:27:40
@quew8 - Thanks!  Glad you're having fun with it.  Please do share images, video. etc of your project when you're done.  Sounds great.

So, yes, this is a bit of a known issue, and I keep thinking I should make a little component for "side-chaining" like this.  You're right that the channel is being switched off as an optimization.  You could switch to using video:composite.  Put the blob processed stream in dst, and the none processed stream in src, with mix on full.  That should do the trick.

Or, create a video:custom and edit the code to -

1  
2  
3  
4  
5  
6  
7  
@In(1) PImage in;
@In(2) PImage sidechain;

public void draw() {
  copy(in);
  release(in);
}


That should also do it.
28  Discussions / General Discussions / Re: Comparison between 2 IDE's - Netbeans and Eclipse on: 2016-09-02 12:05:54

Just amused me because they're practically the same thing.  I do understand the point you were making though.

I will never use IntelliJ IDEA because it's not open source.
You need to get GNU/laid.

No need for that!  I (almost) never use closed-source software either.  There are lots of good reasons for having that viewpoint.  I've been burnt by crappy commercial software that doesn't work very well too often.  I'll stick with the crappy open-source software that doesn't work very well instead thanks!  Grin
29  Discussions / General Discussions / Re: Comparison between 2 IDE's - Netbeans and Eclipse on: 2016-08-31 11:18:54
It's only the community edition.

I said that!  Wink  All three have a liberal open-source license that allows for commercial extension.  There are commercial products built on top of all three.  It doesn't make the community edition any less open-source!  It does make it a little less well featured.  Grin
30  Discussions / General Discussions / Re: Comparison between 2 IDE's - Netbeans and Eclipse on: 2016-08-31 07:15:28
I will never use IntelliJ IDEA because it's not open source.

I fail to see how it (community edition) is any less open source than the other two.
Pages: [1] 2 3 ... 40
 
Galdo (243 views)
2017-01-12 13:44:09

Archive (411 views)
2017-01-02 05:31:41

0AndrewShepherd0 (870 views)
2016-12-16 03:58:39

0AndrewShepherd0 (807 views)
2016-12-15 21:50:57

Lunch (944 views)
2016-12-06 16:01:40

ral0r2 (1175 views)
2016-11-23 16:08:26

ClaasJG (1276 views)
2016-11-10 17:36:32

CoffeeChemist (1309 views)
2016-11-05 00:46:53

jay4842 (1394 views)
2016-11-01 19:04:52

theagentd (1208 views)
2016-10-24 17:51:53
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21
java-gaming.org 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‑gaming.org
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!