Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (744)
Games in Android Showcase (225)
games submitted by our members
Games in WIP (825)
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 ... 37
1  Game Development / Performance Tuning / Re: Java 9 GC on: 2017-11-30 15:15:10
If you're looking to test Shenandoah on Windows, looks like it's available in the 1.8.0.151 ojdkbuild.

That's interesting. I thought that Shenandoah is not suitable for normal applications

(Low-)pause-less GCs sacrifice maximum throughput for lower latency/pauses. Shenandoah has lower throughput than G1GC, but significantly lower pauses. A real-time game would actually value low latency much more than high throughput. Afaik, Shenandoah has been shown to perform well on small heaps too. Also note that Shenandoah increases object size (Brooks pointers).

Maybe the serial GC is all I really need though.

We have apps in production capped to 512MB with SerialGC and pauses are indeed small enough that it's a good tradeoff.
2  Game Development / Performance Tuning / Re: Java 9 GC on: 2017-11-30 11:38:05
Could you describe what Battledroid's doing in the hot path? Are there many allocations? Are there many reference writes (e.g. a BVH getting updated)? This could be a matter of replacing OO code with something more data oriented.
3  Game Development / Performance Tuning / Re: Java 9 GC on: 2017-11-30 11:12:28
It would be useful to see a simple test program that demonstrates bad performance with G1GC. It certainly makes an interesting set of tradeoffs, but I haven't seen an application where enabling G1GC has such a pronounced impact on performance.

Cas, would you be able to post such a program?
4  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3.1.5 on: 2017-11-26 21:03:42
I would really be interested in some runtime performance comparisons with/without tootled meshes. Just curious Smiley

I have converted the demo to a before-after benchmarking tool. It looks like this:



You set up the geometry to test and optimization parameters, then toggle between unoptimized and optimized mesh (with 'O') and see the performance difference. The elapsed time on the upper-right is the GPU time for the 3D mesh only (uses GL_TIME_ELAPSED queries), the HUD rendering does not affect it. Some notes:

1. The meshes 1-8 are procedurally generated using par_shapes. They already have a low ACMR and cannot be optimized significantly, so are not good for testing. The demo supports loading a custom mesh with Assimp (press <CTRL+O>). Artist-created meshes from a DCC app usually suffer from high ACMR.
2. If you don't have a good test mesh, press <SPACE> to shuffle the unoptimized mesh. The geometry is exactly the same, but the triangle order is randomized, resulting in a horrible ACMR close to the worst case (3.0). This should give you a good idea of how bad it can get when the vertex caches are not utilized.
3. When doing ACMR comparisons, it's best to turn off rasterization (press <F> to toggle). This will isolate measurement to the GPU vertex processing pipeline.
4. Overdraw optimization is harder to test. It depends on the mesh having clusters covering other clusters and you also need to be doing significant work in the fragment shader. You may want to edit the shader to do something expensive (e.g. a sin/cos loop). There's also a trade-off involved, optimizing a mesh for less overdraw usually leads to a higher ACMR. This can be tuned with the alpha parameter of TootleFastOptimize. If you want to test for ACMR only, press F1, it usually produces the best ACMR results.

As an example, with the 512 bunnies in the screenshot above and rasterization disabled:

- Unoptimized mesh with an ACMR of 2.075 -> 12ms
- Optimized mesh with an ACMR of 0.689 -> 5.7ms

It's a fairly dramatic difference, but YMMV. It really depends on the mesh used, but it's always beneficial and, well, it's free (can be done offline).

Finally, if you're on Windows, make sure to download the latest 3.1.6 snapshot. It adds support for Direct3D rasterization when doing overdraw optimization/measurement, which makes Tootle at least 100x faster (hundred x, not a typo).
5  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3.1.5 on: 2017-11-22 02:18:32
Is there any chance that there will be EUR donations? For a monthly 2$ subscription my bank will charge me another two just for exchanging the money :S

Open Collective plans to add more payment options in the near future. If it takes too long, we'll consider other solutions.
6  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3.1.5 on: 2017-11-22 02:16:03
LWJGL 3.1.4 has been replaced by 3.1.5. See the updated release notes in the OP for more information.

LWJGL 3.1.5 includes AMD Tootle bindings. It's a library that optimizes geometry to better utilize the vertex prefetch cache and post-transform vertex cache in modern GPUs, while also minimizing overdraw (less fragment shading). Here's a simple demo, everything is done automatically in two simple function calls. Enjoy!
7  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.5 on: 2017-11-20 00:26:53
LWJGL 3.1.5 has been released!

edit: This post was originally about 3.1.4. The build published to Maven Central was incompatible with Java 8, so it had to be replaced quickly with a new version.

3.1.5 release notes
3.1.4 release notes
Download

You can now contribute to LWJGL by becoming a backer on Open Collective with a monthly/yearly/one-time donation to the project. The plan is to use donated funds:

  • to cover server hosting & bandwidth expenses (currently ~$30 per month)
  • to cover software & hardware expenses
  • to offer bounties for documentation work (priorities: adding EGL & GLES javadoc, updating GL)
  • to offer bounties for new bindings
  • to offer bounties for new platform ports (priorities: ARM, Android)

Finally, don't forget to check out the lovely path tracing tutorials created by KaiHH!
8  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-16 12:53:29
That article doesn't say anything about how Ceylon's null handling is better, in practice. It's implemented with union types, which Kotlin does not support. What does that get me?
9  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-16 12:30:57
Sounds like there's a correlation between people liking/disliking Kotlin and choice of favorite IDE.

Ceylon's approach to null safety is years ahead of Kotlin's

I'm curious to learn more, please explain.
10  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-12 15:31:44
I wanted to post a screenshot here to show how you can make Kotlin render type inference in the IDE. As I was going through my code, I realized in how few places it's actually necessary. If you remove obvious types like literals (val x = 10) and constructor calls (val foo = Foo()), I had a hard time finding a good example in lwjgl3. Probably because there are so many single-arg lambdas and I make extensive use of the implicit "it" argument. Anyway, I was more lucky in lwjgl3-vulkangen:



The grayed-out ": Foo" types are virtual, I didn't have to type them. If the right-hand side expression changes, these types are updated automatically. Lots of "it"s in here too, but note how "feature" at line 114 is annotated. Surely, this convenience will be available for Java vars too.

A few other comments based on the discussion above:

- Declaration/use-site variance and type projections: Yaaaaawn... Kotlin generics are indeed cleaner and more flexible than Java's, and you can write pseudo-reified code with inline functions. But it's still generics. There are no meta-programming features and you start hitting the inherent limitations as soon as you try to do anything half-complicated. Like in Java, I use Kotlin generics as little as possible (basically collection-style), anything else is a waste of time and effort.

- Same for data classes, you can't hear about Kotlin without hearing about data classes, but they are really not a big deal in practice. Btw, they're coming to Java. Having the syntax in place will be useful for value types though.

- Pattern matching is nice syntactic sugar. Very simple in Kotlin (when statement), Scala is more powerful there. But I honestly don't get why people get excited about switching on types... since when is that considered good practice? OK, sucks when you have to do it without syntactic support, but if the support is there, it's a huge magnet for novice programmers writing shitty code. Much more so than local type inference.

- Explicit casts in Kotlin look like:

1  
2  
val src: Any = "test"
val trg = src as String

i.e. you write the type once, not twice.

- % of Kotlin in LWJGL: It's the (offline) code generator and binding templates. The generated Java and C code lives in a different repository. The classes you get when you download LWJGL are 100% javac compiled.

- Top Kotlin features for me: extension functions/properties, null-safety/inference, anything that has to do with parameters (final-by-default, named params, default values, varargs, lambdas).

- Now that @princec mentioned it, I would love to see a thread about Clojure and the practical pros and cons of using it. Also, any tips on how to get used to the alien syntax?
11  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 11:04:58
Extensively... but I know enough about Java's goals, limitations, and promises to understand why generics were made the way they were. They could have been made better - but at a cost that would at the time have been completely unacceptable.

FWIW, Kotlin was designed under significant constraints too and the initial plan was different. There aren't any features that cannot be expressed in Java bytecode and having to deal with Javascript was an issue from the get go. A different runtime is required to fix core issues and try radical new ideas (see Go, Pony, Rust).

If I were to design Java again from scratch... it would look remarkably like Ceylon.

It probably wouldn't. When moving to Kotlin from Java, there are two kinds of "weirdness" that you have to get used to: 1) types "on the right" and 2) a few conventions (single-expression functions, last-parameter-lambda, etc). The first has language design benefits, that's why most functional languages look like that. It's also more natural to read (source):

1  
2  
3  
4  
5  
fun isFree(forWhom: Person): Boolean
// Kotlin: function isFree with parameter forWhom of type Person which returns Boolean.

shared Boolean isFree(Person forWhom)
// Ceylon: shared (function) which returns Boolean and is called isFree with parameter of type Person named forWhom
12  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-07 10:21:37
With the new 6-monthly releases I think we're about to see Java evolving much more rapidly, partly as a result of things like Kotlin (eg. type inference and pattern matching next March?).

Definitely. We'll be seeing new language features and new APIs faster from now on. Also in experimental form, which would not be possible if we hadn't already paid the price for Java 9 (the JPMS delays). On the other hand, any bytecode or API features that get added to Java, automatically benefit all languages that target the JVM. Java the language will always lag behind because its creators must be extremely careful and conservative. This is a good thing. We want a stable base/compilation target, experimental languages on top of that can come and go. If there's a great new idea that works, the base can adopt it and everyone benefits (see Kotlin Coroutines and Project Loom).

Another example is "typealias" vs "newtype". The former is supported already. The latter could have been implemented at the compiler level, but Kotlin's creators have decided to wait for the JVM to support value types. Adopting new languages doesn't mean Java is going away. It should always be there and it should be healthy.

I read that Kotlin is fast, but the article was saying fast as in almost as fast as Java, but much faster than Python, JavaScript, others of that ilk. What is the truth on Kotlin's speed?

Kotlin/JVM compiles to Java bytecode. It's as fast as Java bytecode can be on a given JVM. There's no bytecode that javac can produce, that kotlinc cannot reproduce exactly. Kotlin simply has different constructs at the language level that makes "producing bytecode" easier/cleaner/faster.

Kotlin/JS compiles to Javascript. Same as above.

Kotlin/Native uses LLVM for ahead-of-time compilation to platform-specific executables. This is still a work in progress and early to judge performance-wise. It features both explicit memory management and (currently) a reference-counting GC.

I would be wary about any woohoo on multiplatform implementation. Is it proven or in development? There were several woohoo multiplatform attempts with Java that ended up not being as good as initially hoped. Maybe I'm wrong about all of this, since I didn't get that far with my games to follow through on that aspect.

Put it this way, is the iOS for Kotlin similar to the iOS provided by RoboVM for Java?

Kotlin/Native is not a write-once-run-anywhere solution. You'll be making direct calls to platform-specific libraries and APIs. Each platform will be a separate module with different code. What Kotlin lets you do is extract generic code to "common" modules and reuse it in all platform modules.
13  Discussions / General Discussions / Re: Move to Kotlin? on: 2017-11-06 14:21:08
For anyone looking into Java++ languages:

Multiplatform native development in Kotlin

4 applications (server, web, android and iOS), 1 language, 1 project with code sharing.

Also considering other recent advances, like first-class support in Android Studio and Gradle, I'm not sure how Ceylon/Scala could compete with the ecosystem that's been building around Kotlin.
14  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.3 on: 2017-09-22 00:49:20
LWJGL 3.1.3 has been released!

Release notes
Download
15  Discussions / General Discussions / Posting to not-so-old topics on: 2017-08-01 11:10:57
I have a request for @Riven: could we please relax the rule for not posting to old topics? I'm referring to the:

Quote
You cannot reply to this message, because it is very, very old.

lock that is applied to topics that haven't had a reply recently.

As an example, I wanted to contribute useful information to two topics today and both were locked. The first with a last reply on 27 Oct 2016 and the second on 17 Jan 2017. I don't think either topic is that old or long forgotten. Adding my reply to the existing topics is preferable to creating a new topic that references the old. Especially if the reply is a minor contribution to the discussion.

I'm not sure what the current time limit is, but can we maybe increase it to at least a year?
16  Discussions / General Discussions / Re: JGO Twitter List on: 2017-07-26 14:04:34
@iotsakp
@LWJGL (managed by kappa, I mostly post about new releases)
17  Game Development / Shared Code / Re: Faster Than Light JSON Parser on: 2017-07-06 08:32:17
I'd also decide whether the class is going to be stateful, or not.
At the moment you're storing pos as state, but passing the byte[] & ParseListener around as parameters.

Go with one, or the other; doing both looks messy.
Given the aim is minimal weight & dependencies, I'd be inclined to make it stateless so everything can be static.
Either way, I doubt it'd have any noticeable impact upon performance.

This mix of functional/stateless parameter passing and internal state is by design. Because the JVM is the leakiest abstraction in modern software development. Possibly only rivaled by SQL query optimizers.

1. The problem starts with bytecode size. More bytecode in a method == harder for the JVM to optimize.
2. Once you start dealing with bytecode size, you need to extract repeating code and corner cases to other methods.
3. It all ends when you need to return two values from a method. You can't do that without state in Java.

There's a major difference between input/listener and pos. The former is external state, the latter private/internal. The JVM sees that it has full control over pos and is able to perform the full range of optimizations. It's also likely that the entire parser instance can be eliminated via escape analysis.
18  Discussions / Miscellaneous Topics / Re: Passion Projects and Life: Spreading Yourself Too Thin? on: 2017-06-30 22:38:37
I'm in a similar situation with work, family/kids, side-projects and LWJGL competing for my attention. Assigning days of the week (or hours of the day), to specific projects has been inefficient and does not work for me at all. I need long stretches of focusing on a task, for days or weeks in a row, to make meaningful progress. It's usually a few days of research without much coding, or just a little bit of prototyping, then a few more days of actual coding, then several days of validation and polishing. I'm not a good multi-tasker and switching to other projects, even for a day, breaks the flow.

So, another approach you might want to try is: schedule your work in batches. It can be anything from a week to 3 months, where all your free time goes to a single project only. It doesn't even have to be actual work. This week may be LWJGL week, next week might be family/friends week, the week after workout/fitness/personal-time week. Do one thing with your full attention and do it right.

A few more tips:

- +1 for having a reasonably strict schedule for the kids, especially bed time. It's good for them and it's good for you and your spouse.
- Make sure you sleep enough. Every person is different wrt how much sleep they need, but modern life usually means you're not getting enough. More sleep means less time for projects, but it's the quality that matters, not the quantity.
- If you're self-employed and can afford it, add your work to the project rotation. Putting the job on hold for a week may not be the end of the world and it can free up precious time for something a lot more satisfying. I've done this several times while working on LWJGL.
19  Discussions / General Discussions / Re: JCrete? on: 2017-06-29 13:12:07
I was there last year. It's unlike any other (un)conference you may have been to and definitely worth the trip.

The mornings are tightly packed with 5-6 sessions going on at once. Lots of diversity and many interesting topics to choose from (or host yourself). Then you get to visit some of the most beautiful locations in Greece and have amazing food. The most interesting discussions happen in small groups, while driving to a destination, or relaxed on a beach. I was actually having useful discussions up to 2' before boarding my return flight.

No matter what, don't miss the trip to Balos!
20  Discussions / General Discussions / Re: Compressing chunk of tile data? on: 2017-06-28 07:16:23
On the topic of compression, but not necessarily applicable to this use-case, I've been meaning to add a few different implementations to LWJGL. Specifically, I'm interested in compression algorithms that make unusual space/speed trade-offs. For example, Zstandard and LZFSE. Suggestions for other algorithms are welcome. I'm eagerly looking for an rANS-based implementation, like cbloom's Kraken, that is open source.
21  Game Development / Newbie & Debugging Questions / Re: STB Font library with chinese characters on: 2017-06-21 19:34:47
But since it isn't a letter-based system there are THOUSANDS of characters to choose from; i.e. how can I fit them all onto a texture?

Storing every chinese character is generally a waste of memory. The usual approach is to have a caching scheme, i.e. a texture + associated stb packing that gets updated on the fly as new glyphs are required.

The chinese characters stored in unicode are ALL OVER THE PLACE. Which is annoying because with STB you just declare a start and an end, and it fills the middle in with letters. But I need to define a lot of ranges spanning thousands of numbers to store them. I am not quite sure what to do.

Have you tried stbtt_PackFontRanges?
22  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.2 on: 2017-05-15 17:28:18
LWJGL 3.1.2 has been released!

Release notes
Download
23  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3FX - A sneak peek on: 2017-05-04 15:43:36
I would recommend JFXGL, for now at least. Jeff has made good progress.
24  Game Development / Networking & Multiplayer / Re: Best - and currently active - networking lib? on: 2017-04-30 20:08:44
Aeron for IPC and server/server communication, Netty for client/server communication. Also, Vert.x if you're looking for a higher level solution (based on Netty).

Aeron is designed for extremely low latency and destroys every other library in that metric. Many frameworks have started adopting it as their backend. Random examples: Akka Arterty, Onyx, Deeplearning4j. It is highly tunable and has a simple and very focused API. But being a pure transport layer, it doesn't provide any higher level features. Yet. There are plans for more features (by the same creators), either built-in or in new libraries that work closely with Aeron. The next Aeron release is getting persistence and there's Aeron#211 that will make it great for games. Aeron has native support for SBE, but you can use any serialization framework that works on NIO buffers.
25  Discussions / General Discussions / Re: Project Panama - the JNI Replacement (slidedeck) on: 2017-04-05 07:55:32
I don't care about the API at all. I will use it even if it's 10 times harder to use than JNI, as long as it eliminates the performance overhead. We can hide the ugliness in libraries like LWJGL.

My real worries:

1) No matter how good Panama is, there is a strong dependency to Project Valhalla and value types. If that gets delayed (and it very much looks like it will), Panama won't see the light of day, or will have crippled performance. Panama is simple compared to value types. The latter requires serious research and engineering work and there are a lot of open questions. Afaik their priority is on the Java side of things and haven't even touched the fixed/native layout issues yet. Which is expected tbh, there are very few people inside Oracle that actually care about native interop.

2) I doubt we'll be able to use the full power of Panama in user code (custom intrinsics etc). My expectation is that it will be highly restricted for JVM internals (security concerns, Jigsaw bullshit, etc) and we'll again be stuck waiting for Oracle to release the right set of public APIs. What I would prefer instead is that Oracle lays the JVM foundations and the community builds everything else.

3) I'm afraid it's going to be too late for Panama when it is released. Panama, AOT, value types, it will all be great, but when? Even Jigsaw hasn't been released yet (and most people I know hate it already). Meanwhile, projects like Scala Native and Kotlin Native will get the job done.
26  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Nuklear "nk_begin" method causing random SIGBUS after a while. on: 2017-03-19 14:59:08
Change the Font class to hold a reference to the font data buffer (the one loaded with ioResourceToByteBuffer and passed to stbtt_InitFont). The documentation for stb_truetype briefly mentions this:

Quote
The system uses the raw data found in the .ttf file without changing it and without building auxiliary data structures. This is a bit inefficient on little-endian systems (the data is big-endian), but assuming you're caching the bitmaps or glyph shapes this shouldn't be a big deal.
27  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3FX - A sneak peek on: 2017-03-11 08:36:56
There's now an alternative implementation available, JFXGL. It was created by Jeff Martin. Compared to ours:

Pros

- It uses GLFW for context management and as the windowing system.
- You have full control of the render loop (the fixed 1ms per frame overhead mentioned above does not apply).
- Doesn't have the -Djava.ext.dirs issue.
- You can use it right now.

Cons

- It handles JavaFX graphics only, other features are not supported (pickers, popups, etc.).

We've shared our code with Jeff and his code is obviously also available, so both approaches will likely improve soon.
28  Game Development / Performance Tuning / Re: ArrayList$Itr and Escape Analysis on: 2017-03-06 14:06:42
Stop wasting your time with traditional profilers. Treat them like antivirus software; they lie all the time and they are not made to help you. Yes, they're that bad.

Can somebody settle this once and for all...

JVisualVM reports that I'm generating megabytes worth of iterators every frame. This is bothering because there are other things I'd rather have room to create megabytes of every frame. However I've heard anecdotally that it is only the presence of JVisualVM's profiling that actually causes these iterators to be picked up because it turns off the escape analysis feature in the JVM.

This is true, merely the presence of an attached profiler will disable escape analysis and many other optimizations. The simplest way to identify whether EA is kicking in or not is to use JITWatch. It's my favorite performance analysis tool these days. It doesn't require a debug VM or the disasm DLL (though disasm is highly recommended for low-level tuning). Here's a demo of the EA reporting:

<a href="http://www.youtube.com/v/LK1Ain1JDlQ?version=3&amp;hl=en_US&amp;start=" target="_blank">http://www.youtube.com/v/LK1Ain1JDlQ?version=3&amp;hl=en_US&amp;start=</a>

A debug VM will tell you why a particular allocation has not been eliminated. This is useful, but not critical for performance tuning, assuming you're familiar with the basics. Once you identify a problematic allocation, it takes a bit of refactoring to solve the problem and it's rarely an unfixable situation. Like everything else in Java, bytecode size, call depth and associated inlining decisions play the most critical role.
29  Game Development / Newbie & Debugging Questions / Re: [LWJGL3/OpenGL] New window mode versus VAO on: 2017-02-27 08:13:46
What I meant was knowing where to find, read, and learn the information you told me about changes. Is that in the build configurator?

Any changes that affect users are mentioned in the release notes. See the 3.1.1 notes for this particular issue.

Should I just be using all the files given to me in those configurator zips? I got 21 jars from my standard set in the configurator, but I only used 7 before. I didn't seem to need them all, but perhaps I'm wrong?

After you select the bindings you need and download the bundle, you're supposed to use all classes jars and natives jars for the platform you're running on. It's very unlikely that you're going to need all bindings. The configurator remembers your previous selection for a given browser, or you can use the Save/Load functionality when moving between browsers/computers.
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: lwjgl3 compile-native \windows\build.xml:89: apply returned: 2 on: 2017-02-26 10:57:10
I can't find the error in the log. Could you please try "ant clean compile-templates compile-native"? If that doesn't work, post the log again but without verbose Ant output.

Btw, I will update the Nuklear bindings soon anyway.
Pages: [1] 2 3 ... 37
 
Ecumene (150 views)
2017-09-30 02:57:34

theagentd (225 views)
2017-09-26 18:23:31

cybrmynd (303 views)
2017-08-02 12:28:51

cybrmynd (291 views)
2017-08-02 12:19:43

cybrmynd (299 views)
2017-08-02 12:18:09

Sralse (292 views)
2017-07-25 17:13:48

Archive (980 views)
2017-04-27 17:45:51

buddyBro (1105 views)
2017-04-05 03:38:00

CopyableCougar4 (1684 views)
2017-03-24 15:39:42

theagentd (1432 views)
2017-03-24 15:32:08
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
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!