Hi !
Featured games (91)
games approved by the League of Dukes
Games in Showcase (756)
Games in Android Showcase (229)
games submitted by our members
Games in WIP (842)
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
1  Discussions / General Discussions / Re: Oracle wins copyright for the Java APIs on: 2014-05-16 22:45:21
I just don't understand how there is copyright at all when Sun open sourced the java language and API's? Can't everyone use and copy the API as much as they want so long as they abide by the open-source license?

In order for an open source license to exist, you need copyright, otherwise there's nothing to license (you can't license something that isn't your property). In any event, Sun open-sourced the JDK under the GPL, but Google decided not to abide by that license (they didn't want Android to be copyleft). However, they believed that the API aren't copyrightable (and therefor not Sun's to license), so a they took what they believed to be a clean-room implementation (Harmony) of the Java APIs. The question of API copyrightability is an interesting one, but there's little doubt that Google did not have clean hands in this whole affair.
2  Discussions / General Discussions / Re: Writing an MMO with Web Actors on: 2014-02-16 10:37:31 has legit actors

Akka's actors are based on callbacks, while Quasar's employ true lightweight threads. Quasar actors can therefore block and do proper selective receive - just like Erlang.
3  Discussions / General Discussions / Re: Writing an MMO with Web Actors on: 2014-02-13 19:13:23
Is that Query language? i am not really sure  Huh

I don't even understand your question  Smiley
Is what a query language?
4  Discussions / General Discussions / Re: Writing an MMO with Web Actors on: 2014-02-13 19:12:37
are you gona use html for this? cus i dont know how to code it, started little with libgdx,slick2d,lwjgl,tween engine

The standalone version uses JOGL. This uses Java for the server and Javascript+WebGL for the client.
5  Discussions / General Discussions / Writing an MMO with Web Actors on: 2014-02-13 16:46:47
A new blog post.

6  Games Center / Showcase / Super-concurrent Spaceships Demo on: 2013-10-17 07:34:13
<a href=";hl=en_US&amp;start=" target="_blank">;hl=en_US&amp;start=</a>

This demo simulates a space battle using actors an a spatial database. It is by no means optimized for performance, and the implementation is naive: for example, rather than do a single spatial join, each spaceship issues a query to find other spaceships in its surroundings. Still, we get very good scalability.

Read about it here.
7  Discussions / Miscellaneous Topics / Re: A new Java lightweight thread library on: 2013-10-16 15:54:59
We've re-written our spaceships demo to use Quasar's lightweight Java threads. You can read about it here:
8  Discussions / Miscellaneous Topics / Re: A new Java lightweight thread library on: 2013-05-04 17:01:20
That's my point, isn't it better to use a proven solution instead of rolling your own? You also get batch processing, configurable wait strategies and dependency chaining out of the box.

Maybe you're right. I don't know, it just seemed like a bit of an overkill if all I needed was one consumer. I didn't need dependency chaining and configurable wait strategies, and the only wait strategy I needed wan't supported by the disruptor anyway -- fiber-blocking -- so I would have had to do that myself. Also, I wanted to have primitive-type bounded queues, and unbounded queues, too, so an existing solution for one specific type of queue wouldn't have saved much work. You can look at my implementation here and here. It's about 300 lines in total. Primitive queues require a bit more work. See here and here. (Those are just the bounded queues).

Actually, I just remembered, there was one tricky issue here. The consumer holds a pointer to the last item it read in the queue (I use this for selective receives), and because I use both bounded and unbounded queues, that pointer could be either an index or a ref to a linked-list node, so it's gotta be an Object. In the bounded queue case, Martin's queue uses a long index which always increases; the actual index in the array is that index mod the array length. That meant that any time the consumer read a value, a boxed long would have had to be created and could have been held for a long time (i.e., could be promoted GC-wise). I do something a bit ugly. Internally I use Martin's long-index approach, but I give the consumer an int index, which is equal to the actual array index. This keeps the index always to a small int (always less than the size of the array), so increasing Integer's default maximal cached Integer by just a bit, ensures that a the boxed Integer instance is always cached.
9  Discussions / Miscellaneous Topics / Re: A new Java lightweight thread library on: 2013-05-04 01:07:00
Disruptor development, after the initial release, was mostly driven by exactly this case, multiple producers. Even as early as when instantiating a RingBuffer you have to choose between the two major use cases, see the createSingleProducer and createMultiProducer methods. The MultiProducerSequence class is what takes care of multi-thread publishing in the current version.

Yes, but even in that case, the disruptor only helps when you have multiple consumers. For multiple producers the disruptor does the only thing that can be done: a CAS on each insert. The whole idea behind the disruptor was improving the reads, not the writes. Having each consumer hold its own index into the queue and not having the consumers write contended variables is the disruptor's contribution. If you have a single consumer, there's no contention on the read side anyway.

In short, in the single-consumer multiple-producer case, the disruptor is identical to the bounded queue used in Quasar.
10  Discussions / Miscellaneous Topics / Re: A new Java lightweight thread library on: 2013-05-03 14:15:23
Do you have equivalent examples in Java?

There are some Java examples pointed out on the project's page.
You'll find links there to the documentation, too, when it's ready.

Have you considered using the Disruptor for your queues?

The bounded queues are implemented very similarly to the disruptor. Are you suggesting one disruptor to replace all queues? If so, I don't think the disruptor would make a good choice. The disruptor especially shines when you have one producer and multiple consumers (each consumer updates a non-shared index to the last read item, while the producer simply needs to increment a volatile index to mark the last entry written). In fact, if you've seen the original LMAX talk, that's precisely what the disruptor was designed for. But here the problem is the opposite: we have multiple producers but only a single consumer.
11  Discussions / Miscellaneous Topics / A new Java lightweight thread library on: 2013-05-02 22:55:10
I discovered Matthias Mann's continuations library when Riven showcased it on these forums. I then put (a modified version of) it on top of fork/join and the result was  Quasar: If you're interested, you can read about Quasar, and its Clojure API, Pulsar, in this blog post:
12  Discussions / General Discussions / Re: A New Approach to Databases and Data Processing — Simulating 10Ks of Spaceships on: 2013-03-01 09:42:33
The demo is open-sourced under the MIT license, and SpaceBase itself is available for download, with full documentation, here:

The post was meant to give the theoretical background. I believe you can find all the details in the user guide and the demo code.
13  Discussions / General Discussions / A New Approach to Databases and Data Processing — Simulating 10Ks of Spaceships on: 2013-02-28 12:03:40
Yesterday I published a new blog post on our company blog:

It showcases a 10Ks spaceship battle simulation we've built on top of our spatial DB, which was built in Java. The point of the post is not to show how fast the simulation can run because there are faster ways to do it. The idea is to show how even a naive solution running on top of the right kind of database can achieve decent performance and good scaling.

I think some of you may find this interesting.
14  Discussions / General Discussions / Re: Go on, ask me anything. on: 2012-08-12 22:56:50
Could you please elaborate on Webstart's shortcomings?
15  Discussions / General Discussions / Re: Introducing SpaceBase and Galaxy on: 2012-08-12 20:26:42
I do not have multiple servers (barely one scavenged). Is SpaceBase (or Galaxy) still suitable for me?

SpaceBase absolutely is. Galaxy is only necessary when you want to cluster SpaceBase or any other component of your game (and is not yet production ready).

SpaceBase isn't free, but we do offer startup pricing. As for the evaluation version - it is time-limited.
16  Discussions / General Discussions / Re: Introducing SpaceBase and Galaxy on: 2012-08-12 03:53:02
That's all a bit too deep for me, but good luck anyway!

 Smiley Thanks!

... and just to make things simpler: SpaceBase lets you track lots of moving objects, query them very quickly, and helps with making your game multithreaded.
(and Galaxy will help scaling MMOs seamlessly in a cluster, but it's a very low-level framework that requires building a lot on top of it).
17  Discussions / General Discussions / Re: Introducing SpaceBase and Galaxy on: 2012-08-11 20:25:00
18  Discussions / General Discussions / Introducing SpaceBase and Galaxy on: 2012-08-11 01:08:58
Hi! I'm a long-time lurker and a very occasional poster on these forums, but I'd like to introduce some of the things I've been working
on for the last few years, that I think will be of interest to many here.

The first is a new server-side middleware product for MMO games called SpaceBase ( To MMO games, SpaceBase is two things: a low-latency 2D/3D spatial data store, and a concurrency/parallelization framework.
At the heart of SpaceBase is a state-of-the-art non-degrading and highly concurrent variant of the R-Tree that's the core of the spatial data store. Unlike other spatial databases, SpaceBase is especially designed for tracking objects that are constantly moving. You put your game objects into SpaceBase, update them as they move, and perform region queries or spatial joins (say, for broad-phase collision detection). A single update takes ~15us, and a region query (returning ~5 objects out of 2 million) takes ~1.5us. That's in terms of latency. In terms of throughput, because the underlying data-structure is highly-concurrent, you get nearly linear scalability with the number of threads (depending on how much they trample on each other spatially). In addition, SpaceBase can parallelize even a single query using the fork/join framework.
The other use for SpaceBase is as a concurrency/parallelization framework. If you write your game's server not as a game loop, but in an event-based manner, you can pass your game logic, physics simulation, AI, etc., as callback to SpaceBase transactions/queries, and SpaceBase will execute them in the fork/join threadpool managed by SpaceBase, taking care of all synchronization for you. SpaceBase employs both lock-free techniques to minimize contention and cache-faults, as well as locks especially built to work hand-in-hand with fork/join for long-running transactions. Those locks don't reschedule threads but, rather, reschedule fork/join tasks.
SpaceBase is implemented in Java and is intended to run embedded in the game process. It is proprietary, but we'll gladly send evaluation copies to anyone who wants to try it out.

The other project I'd like to introduce is an open-source in-memory data grid called Galaxy ( In the near future SpaceBase will be able to run on top of Galaxy to scale horizontally in a cluster. But even when used without SpaceBase, Galaxy can be of use to MMO serveres that require horizontal scaling. Unlike all other IMDGs (Ehcache, Gigaspaces, Infinispan, Gemfire, Coherence, Hazelcast) that use a distributed hash-table (DHT) approach, Galaxy employs a software implementation of a cache-coherence protocol similar to the ones used to coordinate L1 caches in CPUs.
DHTs partition their objects based on their key's hash, so for every object they quickly know which node it resides on. They have a worst-case scenario of 1 network hop per object access, but that's the common case as well. Galaxy takes a completely different approach. It migrates objects from node to node as requested. The result is that while the worst case for an object access can be more than 1 network hop, the common case is 0 hops.
Galaxy is meant to serve as a platform for building distributed data-structures. For example, when SpaceBase runs on top of Galaxy, as the objects move in space, they also migrate from one cluster node to another, keeping nearby objects on the same node, while trying to maintain a similar number of objects per node. The result is a dynamically expanding/shrinking "region" nodes.
This blog post explains the reasoning behind Galaxy's architecture:, and this three-part series describes Galaxy's implementation in detail:
Galaxy is distributed under the LGPL, and is still considered experimental. You can find it on GitHub here:

I would love to get your feedback!
19  Discussions / General Discussions / Re: Eclipse vs. Netbeans on: 2011-03-24 11:24:08
On the other hand, I've never heard of jGRASP until now, and, having taken a look at it, think that, while perhaps ugly, it does have some cool features that other IDEs could benefit from.
What features does it have that others don't?

Well, the "Control Structure Diagrams" (those little graphics on the side of the code) - they look nice - and the viewers (that show a graphical representation of a data structure) - they look cool, too. These can't be found in Eclipse or NetBeans.
20  Discussions / General Discussions / Re: Eclipse vs. Netbeans on: 2011-03-23 11:23:22
I've used both Eclipse and NetBeans extensively in professional settings, and while I have a slight preference for NetBeans, as IronclawsBt said, they're both excellent tools and the choice between them comes down to personal preference. I've never used IntelliJ but have heard great things about it as well.
On the other hand, I've never heard of jGRASP until now, and, having taken a look at it, think that, while perhaps ugly, it does have some cool features that other IDEs could benefit from.
21  Discussions / General Discussions / Re: Early reports on JavaFX 2 are in. on: 2011-02-27 12:56:05
@Joe: Thanks for the answers. You've certainly built up my expectations.

...and i also wrote the binding API for PhysX  Cool.

Wait, what? Is there a JavaFX API for PhysX?Huh?

22  Discussions / General Discussions / Re: Early reports on JavaFX 2 are in. on: 2011-02-26 18:53:47
@Joe: Sorry we're bombarding you with questions, but we've been left in the dark and would really like to know what to expect, so we can plan for the future. What about the SlimShady project? Is its development ongoing? It was meant to be better than prism for hardware acceleration, wasn't it?
23  Discussions / General Discussions / Re: Early reports on JavaFX 2 are in. on: 2011-02-18 15:33:43
Here's a new interview with Stephen Chin, maker of the Visage language, on JavaFX 2:
24  Discussions / General Discussions / Re: Early reports on JavaFX 2 are in. on: 2011-02-18 11:59:37
There is already a Java2D/JOGL integration

I know, but it was done by Sun, and required Java2D to expose its OpenGL pipeline. I believe Oracle would have to do the same with JavaFX (expose the OpenGL pipeline) in order for the integration to be possible.
25  Discussions / General Discussions / Re: Early reports on JavaFX 2 are in. on: 2011-02-16 17:19:28
Actually I would like to use JavaFX only for its 2D GUI elements and another scenegraph instead of porting any code to Prism.

Hmm, kinda like the Java2D/JOGL integration? I doubt this will be possible without help from Oracle. They'll need to expose their OpenGL context, won't they?
26  Discussions / General Discussions / Re: Early reports on JavaFX 2 are in. on: 2011-02-16 12:17:44
It might not be needed, Im sure it will contain its own way of handling 3D.
I don't want to rely on Java3D and I prefer using tougher scenegraphs like Ardor3D, JMonkeyEngine, ...

JavaFX is the scenegraph. If you're not using it for rendering then you're not really using JavaFX. You probably mean the new AWT-less plugin with other windowing system. Well, maybe that'll be possible, too, but I think that LWJGL/JOGL would have to adapt to use JavaFX's windowing, if some direct access to it is provided.
27  Discussions / General Discussions / Re: Lots of doors are being closed for Java on: 2011-02-16 12:12:11
How about manipulating the DOM (including the canvas with or without WebGL) from a "headless" Java applet? Of course, it would not get around the need for the user to have a current JRE, but it may work around JavaScript's performance, if that is the performance bottleneck at the client and not the DOM itself, as well as (possibly) the applet loading time. It is possible right now, but currently applets require AWT. Perhaps with the new AWT-free plugin scheduled for Java 7 this would be an interesting solution.
Manipulating the DOM using the Java language isn't fun, but perhaps with a different JVM language, like Visage, it could be done as well as with JavaScript or even better.
28  Discussions / General Discussions / Early reports on JavaFX 2 are in. on: 2011-02-14 13:29:29
Initial impressions on JavaFX 2 EA have started coming in, and they seem very enthusiastic:
See and links on
The podcast linked on the second page mentions a new non-awt plugin to be out in Java 7, and full 3D (with 3D primitives and complex animations) in JavaFX 2.1.

29  Discussions / General Discussions / Re: Lots of doors are being closed for Java on: 2011-02-10 17:02:31
@Roquen: Exactly, and that's why I said that serious, high-performance server-side programming is done almost entirely on the JVM. Akka is probably a great substitute for Erlang, and since more and more is moving server-side, I believe Java's place in game programming will only grow.

@Cas: I have high hopes for JavaFX 2, too, but in retrospect, I'm not sure Sun's negligence turned out so bad. The fact is that client-side is fragmented, and the only technology in consensus is the committee designed and non-proprietary HTML+Javascript. That's the way the leading hardware vendors want it. They don't want WORA. Apple doesn't want Flash. The Playstation and the Wii don't want to share games. Differentiated software sells differentiated hardware. No proprietary standard stands a chance. However, the client world is becoming so fragmented, with so many different types of devices, OSs and programming language, that developers simply won't put up with it for long, and there will probably be one or two victorious software technologies. Should Oracle put itself into this dangerous competition, especially without client hardware of its own? Well, I'm sure people in Oracle are pulling their hairs out in frustration over Sun not inventing Android, but that ship has sailed. What should they do now? It's a very difficult question. The best result they're hoping for (and the one which will probably be best for the Java community) is some sort of a favorable settlement with Google over Android, which will allow them, and "standard" Java to put its foot in that door.
Other than that - they should hold on and fortify their position on the server, and do well with JavaFX2 to make up for lost developer mindshare.
30  Discussions / General Discussions / Re: Lots of doors are being closed for Java on: 2011-02-09 10:57:13
@ pron
I just read an interview with Joshua Bloch where he specifically mentions Java's concurrency handling as a big positive, given the growing use of multicore processing:
It's funny because it seems very popular to talk about Java being dead now. I see it as histrionics, basically. But I think that right now the best existing multithreaded building blocks are in Java. I think Java is poised for a little resurgence. I'm not saying it is where we'll be headed for the next 20 years; that it is the best way to take care of these multicores. But I think of what's available today, it's head and shoulders above the competition.
The interview is in this book: "Coders at Work--Reflections on the Craft of Programming" edited by Peter Seibel (2009).

Yes, that's what I was saying. It's those other technologies that have a problem with concurrency. Look how beautifully Java-world languages and frameworks make use of concurrency: look at Lift, Akka, Clojure, Cassandra, Hadoop. If you want to make a serious, high-performance, complex, server-side program to support all those mobile devices, you must make it concurrent, which leaves you with only two choices - Java (the environment, not the language) and Erlang. And how many Erlang programmers are out there?

Actually, I think that few serious online games will NOT be written in the Java ecosystem in the next several years. Yeah, the client is really important, too, especially to capture the hearts and minds of young programmers, and Oracle should put more emphasis on that, but I think Java's position in the gaming industry will only grow stronger, and, in fact, it already is growing.
Pages: [1] 2
DesertCoockie (53 views)
2018-05-13 18:23:11

nelsongames (84 views)
2018-04-24 18:15:36

nelsongames (75 views)
2018-04-24 18:14:32

ivj94 (760 views)
2018-03-24 14:47:39

ivj94 (88 views)
2018-03-24 14:46:31

ivj94 (644 views)
2018-03-24 14:43:53

Solater (103 views)
2018-03-17 05:04:08

nelsongames (185 views)
2018-03-05 17:56:34

Gornova (427 views)
2018-03-02 22:15:33

buddyBro (1087 views)
2018-02-28 16:59:18
Java Gaming Resources
by philfrei
2017-12-05 19:38:37

Java Gaming Resources
by philfrei
2017-12-05 19:37:39

Java Gaming Resources
by philfrei
2017-12-05 19:36:10

Java Gaming Resources
by philfrei
2017-12-05 19:33:10

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