Hi !
Featured games (88)
games approved by the League of Dukes
Games in Showcase (679)
Games in Android Showcase (194)
games submitted by our members
Games in WIP (732)
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 ... 34
1  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-05-27 20:11:59
Some examples:


Btw, a Scope object is "a unit of resources allocation that can be released all together". The current prototype has the NativeScope and HeapScope classes. The later uses long[] as the backing memory (on which you can map structs etc).
2  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-05-27 14:15:41
Any mention of stack allocation and value types in the same sentence makes me wonder whether they're going to design what we actually need or whether they're just going to go off on one and make something almost but not quite entirely wrong.

The current Panama prototype supports "machine code snippets". You can write some code outside the JVM/JDK that makes the JVM inline and JIT-compile a method handle to one or more native CPU instructions (of your choice) that also play well with the JVM register allocator. This functionality alone could be used by a library to do amazing things.

API-wise, I wouldn't expect anything pretty without syntactic sugar. But it is true that it is designed under the assumption that Java 10 will have value types and any-generics. This, in theory, will allow Java-ish code to perform just like native C.
3  Discussions / General Discussions / Re: RSS feeds for JGO still broken since October 2015 on: 2016-05-25 14:34:04
I use RSS (via Inoreader too) to follow people that have interesting blogs, but are really annoying on Twitter.
4  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Build Tool on: 2016-05-18 15:18:25
Kotlin Meets Gradle
5  Game Development / Newbie & Debugging Questions / Re: [LWJGL] Choosing your GPU on: 2016-05-16 18:37:52
There is an open issue related to this, currently targeted for GLFW 3.3.
6  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3 - LMDB bindings on: 2016-05-02 19:10:05
There's a new lmdb branch in the LWJGL 3 repository that implements bindings to LMDB. It's an embedded key-value store that may be used for all kinds of persistence, from game settings to shaders, models and textures (binary values up to Integer.MAX_VALUE in size are supported).

See this presentation to understand what's special about LMDB.
See this LWJGL sample for a demo of the API and an example of zero-copy string persistence.

The nightly builds do not include LMDB yet, you'll have to clone LWJGL and build locally to give it a try. I'll decide what to do after the 3.0.0 release, but it's definitely small enough to embed in the standard LWJGL distribution. Please let me know if you're interested.
7  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-05-02 11:04:33
Thanks, fixed in 3.0.0 build 81.
8  Java Game APIs & Engines / OpenGL Development / Re: Mutithreaded LWJGL - Works... Sometimes on: 2016-05-01 07:25:46
what will happen if I add a glfw key callback to the child threads? Will they still be called back, or do I have to track which window is focused myself?

You can't, glfwSetKeyCallback can only be called from the main thread. The same is true for glfwPollEvents, so all events will be handled on the main thread too. If a rendering thread needs to know whether it's corresponding window is focused or not, you must pass that information from the main thread to the rendering thread.
9  Java Game APIs & Engines / OpenGL Development / Re: Mutithreaded LWJGL - Works... Sometimes on: 2016-04-30 17:14:47
I was looking for a tutorial like that! I'm implementing the countdown and a bunch of other stuff now.

Note that you don't have to use a CountDownLatch for synchronization/communication, that's just an example. The only important detail is: most GLFW functions are called from the main thread, the per-window threads only deal with rendering.

This does imply that, at some point, you have to have synchronization points and/or pass messages between threads. Neither GLFW nor LWJGL have any special requirements for how that happens, it's entirely up to the application and how it's designed. Fortunately, Java has a very rich set of concurrency primitives (like CountDownLatch) and concurrent data structures that can be used for that purpose.

I meant to ask, does input handling per window still work regardless of the main thread?

The only thread that deals with window/input events is the main thread. It works fine regardless of how many windows or rendering threads you have.

10  Java Game APIs & Engines / OpenGL Development / Re: Mutithreaded LWJGL - Works... Sometimes on: 2016-04-30 07:06:19
Here's the run method, which is pretty unimpressive (I really just threw it together with some stuff I found online, it worked for a little while, then the glfwInit started crashing the VM)
public void run() {;

    glfwSetErrorCallback(errorCallback = new GLFWErrorCallback() {
        public void invoke(int error, long description) {
            System.err.println("glerror occurred: " + error);
    if (glfwInit() != GL_TRUE) {
        System.err.println("Error initializing GLFW");

You cannot call glfwPollEvents before glfwInit. If glfwSetErrorCallback was above the glfwPollEvents call, you'd see the error.

Also, calling glfwInit and handling the event loop in arbitrary threads is not supported. The design of GLFW is similar to AWT/Swing/JavaFX; event processing must happen in a single thread. See the Threads sample for the correct way to handle multiple windows/threads.
11  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-04-28 15:54:02
Also, the window icon support is very limited right now.

What exactly is missing? If you mean OS X icons, that's up to the application bundling and outside GLFW's scope.

I still can't actually use it commercially, myself, because GLFW still doesn't have buffered controller input :/

A few points:

- GLFW was originally supposed to be one of many windowing/input backends in LWJGL 3. Users have been pretty happy with it so an alternative has not been considered so far, but we're open to suggestions.
- Partial replacements is another possibility (OIS?).
- Issues that affect commercial applications get top priority. Let us know please!
12  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3.0.0 release candidate on: 2016-04-27 14:32:28
GLFW still cannot be started on the AWT thread without it's event loop.

Note that this is a problem only on MacOS. In any case, GLFW does not know anything about AWT and is not supposed to interoperate with it.

The JAWT bindings are there for users interested in implementing LWJGL 2's AWTGLCanvas on top of LWJGL 3. Example code here.
13  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.0.0 release candidate on: 2016-04-27 13:58:26
The current LWJGL 3 nightly build is the first 3.0.0 release candidate.

Now is the time to try it out and report any instabilities or raise any issues you might have with the API. See this post for changes since 3.0.0b.
14  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android on: 2016-04-27 11:46:43
@Spasi I'm not really sure if we're talking about same thing, but for me the strength of 3rd party library is the abstraction over the display and input; no need to poll/listen/draw using platform specific APIs. I  don't know how people use the GL with relation to Java though it's true I see most people use engines/libs like LibGDX or JME, not directly; never have seen anybody writing a native code to optimize stuff (but I'm not really in the so serious business).

There would be two ways to use LWJGL in Android:

1) Use LWJGL for OpenGL ES or Vulkan and use Android APIs for display and input.
2) Replace Android APIs with GLFW for display and input. Currently the problem with GLFW is that it won't support touch events until version 3.3.
15  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3 vs JOGL on: 2016-04-27 11:34:50
I'm obviously biased and won't try to compare LWJGL with JogAmp or list LWJGL's pros/cons. I'll just say that there are differences in philosophy between the two libraries and in what they try to do and not do. JogAmp does things I wouldn't want any library to be doing for me.

Having said that, I have to reply to this:

This reflects in jogl being faster by about 3-5% over lwjgl based on some benchs, strictly opengl call bound

For those that are not aware, LWJGL performs a thread-local lookup on every call to OpenGL. It's the only way to make the static nature of the API work. This also applies to OpenGL ES and OpenAL, but not other bindings (e.g. OpenCL or Vulkan). This may sound expensive, however:

- It's been like that since the first LWJGL version. If it was fast enough in 2002 and Java 1.4, it's fast enough now.

- You can barely measure the performance impact. It's certainly nowhere close to a 3-5% overhead. It's not measurable in real-world OpenGL applications and in fact it's quite hard to measure even in micro-benchmarks (e.g. I had to use JNI methods that do nothing).

- LWJGL 2 optimized the lookup by caching the last thread that called an OpenGL method. This has been removed in LWJGL 3, since it's more common to have multiple threads/contexts these days. It has been replaced with an efficient (but somewhat "hacky") O(1) lookup. java.lang.ThreadLocal is not used by default.

- In the (very very unlikely) scenario where this lookup has a measurable performance impact for your app, you can cache OpenGL function pointers and use LWJGL's (publicly available) JNI/"unsafe" methods. This is one of LWJGL 3's non-obvious features: if LWJGL can do it internally, so can the user. If the user doesn't like the way LWJGL implements something, they can replace it with a custom implementation.

- In the (very very common) scenario where the application either a) creates a single OpenGL context only or b) all OpenGL contexts are created on the same device and with the same context creation flags, you can use
(or launch the JVM with -Dorg.lwjgl.opengl.capabilities=static). This completely eliminates the thread-local lookup and in fact JIT compiles to more efficient code than even JOGL's way. This option is also available for OpenGL ES and OpenAL.

In general, LWJGL 3 has undergone extreme performance tuning. A lot of work has gone into that front the past few months and it's one of the main reasons 3.0.0 is not released yet. The way buffers, arrays and structs are handled in LWJGL and JogAmp are completely different and LWJGL has the upper hand in all situations. If anyone has doubts or thinks otherwise, I'm willing to discuss technical details and accept any benchmarking challenge.
16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android on: 2016-04-27 10:28:55
check out LibGDX, which uses LWJGL3 (and 2 if you prefer) and builds to both desktop and android (and ios)

Just to be clear: This isn't a question of whether it's possible to take a library that normally targets PCs and making it run on Android or other resource constrained devices. I'm sure you can do that with most, if not all, libraries. The real question is: what does it offer over what's already available on the platform and will people use it?

With LWJGL, the above question can be made more specific:

- LWJGL 3 has been designed for modern JVMs (i.e. Hotspot -server). All choices related to API design and performance-tuning have been made after testing on such JVMs. Are the same choices optimal on Android? (very likely not)
- Android already has EGL/OpenGL ES bindings. It's missing Vulkan atm, but it's probably coming. Why would anyone use a 3rd-party library for that? Also, we're talking about Java code calling GL/VK functions... does anyone even do that these days? I'm under the impression that most serious developers prefer using the NDK and going to native code for performance sensitive stuff.
17  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android on: 2016-04-26 15:19:50
since the LWJGL docs seems to be almost non-present

Not sure what you mean. LWJGL has a site, a forum, a wiki, github issues and ~75MB worth of javadoc.

Does LWJGL3 applications can be run on Android? Is there a support for touch events, or perhaps accelerometer? Simply: what about the interoperability between LWJGL3 and Android devices? Could somebody elaborate on this topic?

The next steps for LWJGL, after the 3.0.0 release which is coming soon, are:

- ARM builds for devices like the Raspberry Pi.
- Android support, if it makes sense.

For the second point, I recently bought an Nvidia Shield to explore if there's a viable approach. I wouldn't get too excited though, because one or more of the points below are quite likely to happen:

- It will suck and there won't be any support.
- LWJGL for Android will be a different library than standard LWJGL (will have different bindings and different core API).
- The minimum supported Android version will be (too) high.
18  Java Game APIs & Engines / Java Sound & OpenAL / Re: Java OGG API with concurrent playback on: 2016-04-17 09:44:40
LWJGL 3 comes with bindings to stb, which includes stb_vorbis for Ogg Vorbis decoding. You can read the documentation here and explore a simple music player here (demonstrates streaming and seeking).

An stb_vorbis decoder cannot be used from multiple threads, but you can have multiple decoders decoding independently in multiple threads (which is what you need afaict).
19  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-04-12 23:06:06
Made a short demo of LWJGL 3's Vulkan documentation:

<a href=";hl=en_US&amp;start=" target="_blank">;hl=en_US&amp;start=</a>
20  Discussions / Miscellaneous Topics / Re: lambdas rant on: 2016-04-09 23:36:07
But if IntelliJ can convert my dinosaur code to lambdas automtically, why do I have to use the lambda syntax to get the benefit of (1) no anon class creation and (2) private static method generation?

Technically, you could get the same benefit via escape analysis. But that's too sensitive to inlining decisions and various thresholds. With a lambda, the semantics are clear and the JVM doesn't have to do a lot of work.
21  Discussions / Miscellaneous Topics / Re: lambdas rant on: 2016-04-09 22:52:06
Does it have any advantages aside from being more terse? I don't think any programmer is bottlenecked by their typing speed Smiley Doesn't it produce the same bytecode either way?

No, lambdas are compiled to invokedynamic factories. More info here and here. This means that there's no anonymous class generated at compile-time (the MyClass$1, MyClass$2, etc, classes you get without lambdas). An advantage for non-capturing lambdas is that there's no class generated at run-time either; the lambda may be implemented with a private static method = invokestatic over invokeinterface and no GC overhead.
22  Java Game APIs & Engines / Java Sound & OpenAL / Re: How playback audio data with several audio card's simultaneously uses LWJGL on: 2016-04-07 22:14:04
The ALC_ALL_DEVICES_SPECIFIER query returns a null-terminated list of null-terminated strings, but the normal alcGetString can only handle a normal string. LWJGL provides the ALUtil.getStringList() method for this special case. The alcGetString javadoc mentions this.
23  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-20 12:44:37
After updating, my shader compiling and linking log handling code started crashing due to having a maximum length of 65536 chars, since the buffer was stack allocated and the stack was too small.

This has been fixed in the latest nightly build (#53), by allocating variable size buffers on the heap.

Also, a reminder: you can tune the default stack size with
Configuration.STACK_SIZE.set(n); // n is in kilobytes
24  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-18 15:34:23
In theory Wayland would be just great. Still some question over mouse/keyboard/touch of course.

Cas Smiley
LibInput seems to be the most commonly used library by Wayland compositors to handle mouse/keyboard/touch. As the backend is still experimental not sure input support has been added yet but should eventually just be as simple as using GLFW's api to handle input.

Looks like there already is support for mouse and keyboard in GLFW's Wayland backend. Uses Wayland APIs and xkbcommon.
25  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-18 00:46:44
I am eagerly awaiting LWJGL on the Pi (headless?)

My guess is it requires Pi-specific APIs. Could you please point me to a working sample/tutorial that does headless OpenGL?
26  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-16 22:49:39
Thanks Catharsis. I can't think of anything though, the Vulkan bindings were straightforward and haven't had any issues.
27  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2016-03-16 14:35:46
I just don't want to have to write the same thing twice. Especially on the same line of code.

Totally agree. Which is why I like the var/val/auto proposal. I don't get it, how you can dislike redundancy and JEP 286 at the same time? Especially since it's going to be applicable only to local variable declarations, not field declarations like other languages.

Both type inference and smart casts are supported (perfectly imho) in Kotlin, you can give it a try to see how it'd feel like. Needless to say, I'd love to have both in Java. Another thing that Kotlin got right is primitive casts, they are never done automatically (this sounds worse than Java, but no, it isn't). Btw, nothing about all this requires runtime support, it's all done statically and safely at compile time, i.e. any incompatibilities after type/cast inference are reported as compile-time errors.
28  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-14 17:33:31
A new build is up (3.0.0 #48).

a) There's a new Configuration.THREAD_LOCAL_SPACE option (or -Dorg.lwjgl.system.tls), you can use it to set the thread-local implementation. Supported values:

- "FastThreadLocal", Riven's implementation, the default.
- "unsafe", an implementation using Unsafe.
- "ThreadLocal", standard java.lang.ThreadLocal.

I don't expect significant, if any, gains from this, but if you try all 3 in a real-world application and have performance figures to share, please post here.

b) The stack implementation has been rewritten. It now has documentation, uses correct terminology and grows "downwards" like a native stack. Also made it static in size, the previous implementation was broken. Use the Configuration.STACK_SIZE option (or -Dorg.lwjgl.system.stackSize) to set the default size. The value is in kilobytes, defaults to 32.

c) I wasted too much time on performance testing again, this time the problem was that struct allocations in tight loops were inexplicably less optimal than buffer allocations.

In both cases I verified that escape analysis eliminated object allocations, but timing and JITWatch showed worse code generation. The problem manifested even when not touching the allocated struct object at all. The problem went away if I used Unsafe.allocateInstance to create the struct object, which is what LWJGL does internally for buffers that are not allocated via ByteBuffer.allocateDirect. After a while I figured out that the problem was final fields in the struct class.

Having any final field in a class (or its super-classes) causes the JVM to emit a memory barrier after the constructor has run. To understand why and the implications of this, see All Fields are Final. Normally this is fine, it's the desirable behavior in multi-threaded environments and has virtually no impact on ordered architectures (the barrier is a no-op on x86). But:

- The instances in my tests were eliminated via escape analysis. This means, by definition, that safe publication is not an issue because the object data will only be accessed by the current thread. The JVM already eliminates synchronized locks in such cases.
- The issue continued to occur when the final fields were not even accessed. There was nothing about those fields in the generated assembly, yet the barrier was still there.

For example, in code like:

class Data {
    int x;
    int y;
    final int foo;

int test() {
    Data d = new Data(...);
    return d.x + d.y;

You always pay the cost for that final "foo" field, even if you don't use it at all.

Note that, in my tests, the barrier was not an actual CPU instruction (as I said, no-op on x86) but a compiler barrier. That is, all the loop unrolling and loop invariant code motions that I usually see in code that used buffers, was not happening in similar code that used structs. Removing all final modifiers made all the optimizations kick in.

Luckily, there has been a lot of work on JMM-related issues in Java 9 (see Shipilev's blog post for some examples). I was able to track down a post that mentions this issue, a first attempt to fix it and, finally, the actual fix that made it into Java 9. So, good news is that the unmodified struct code runs with top performance on recent Java 9 builds. But LWJGL has to run on Java 6+, so I'll have to compromise and trade good Java code for performance. If the fix is back-ported to Java 8, I'll restore the current code. Initial testing shows the workaround is a win on all Java versions before 9.
29  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-13 13:58:50
why the asymmetry between nmalloc and ncalloc parameters?

The C malloc and calloc functions have the same asymmetry.

Also, in LibStruct I had cases where num*size overflowed, so I converted malloc/calloc to use longs as inputs.

Technically possible, but why would anyone try to allocate > 2GB on the stack?

You also have the assumption that the 'alignment' parameter is POT - you might want to enforce that.

Thanks, will do.
30  Discussions / General Discussions / Re: Vulkan 1.0 Release on: 2016-03-13 02:26:00
Ehm... which benchmark loop? It's a little presumptuous to think I would make such a rookie mistake when analyzing performance. Smiley

Like I said, maybe the JVM has optimized ThreadLocal performance these days, causing the FTL performance to be only 3-4x faster than TL, but when I was optimizing my demo, the framerate increased significantly, while I did maybe only a few 100k push/pops per frame, processing tens of millions of triangles, in code that I assume was way too big to fully inline, but I may be wrong there. I actually had quite an elaborate demo (still in the LibStruct repo, called SoftlyLit). In the end I even dropped FTL because it was not fast enough for my purposes (proving the JIT had not optimized it away entirely), opting for passing the stack reference as an argument to the methods that needed it. I had multi-threaded demos too, that did much more than pushing and popping the stack, so the measured performance jump was observed in a real world scenario (as far as demos can be considered as such).

FWIW, I tested ThreadLocal from Java 6 and up: ~14ns on Java 6, ~8ns on Java 7, 8, and 9.

FTL and the unsafe implementation get that down to 2-3ns.

Having said all that, you can take the concept of FTL and implement it into LWJGL. Smiley
As for credit, you can add @author Riven to the javadoc. Pointing


- VkInstance and VkDevice seem to want the create info struct now as well. What do they need that information for?

LWJGL uses the apiVersion and ppEnabledExtensionNames fields to build the VKCapabilities objects for VkInstance and VkDevice. Vulkan does not provide a way to query the enabled extensions, so it has to be done like that.

Forgive me for stating the obvious, but implementing this on the Java side is easy as hell. I assume the code generator doesn't support this which is why you want to avoid it?

I would be interested to know what you mean exactly. As KaiHH said, we've explored the possible approaches extensively and the current design had the best trade-offs. It'd be great if you have a better idea that we could discuss. It's easy to implement anything in the generator, but it would have to make sense.

The latest nightly build (3.0.0 #47) includes a stack allocation API. See the org.lwjgl.system.MemoryStack class (warning: WIP + no documentation). Struct classes have been augmented with stack allocation factory methods:

malloc(MemoryStack); // explicit stack

mallocStack(); // thread-local stack

// similarly for struct buffers

Example usage: a) thread-local b) explicit

One possible improvement is to remove the need to call push(). It could do it automatically the first time you allocate after the last pop().
Pages: [1] 2 3 ... 34
Hydroque (17 views)
2016-05-26 14:45:46

Mac70 (39 views)
2016-05-24 21:16:33

theagentd (42 views)
2016-05-14 18:38:35

theagentd (76 views)
2016-05-10 22:37:41

theagentd (84 views)
2016-05-10 22:33:46

IanParcs (110 views)
2016-04-18 14:18:53

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

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

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

theagentd (157 views)
2016-04-14 02:15:43
FPS Camera Tutorial
by Hydroque
2016-05-22 05:40:58

Website offering 3D Models specifically for games for free
by vusman
2016-05-18 17:23:09

Website offering 3D Models specifically for games for free
by vusman
2016-05-09 08:50:56

Website offering 3D Models specifically for games for free
by vusman
2016-05-06 11:10:21

Website offering 3D Models specifically for games for free
by vusman
2016-04-29 12:56:17

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

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

List of Learning Resources
by SilverTiger
2016-02-05 09:35:50 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!