Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (749)
Games in Android Showcase (227)
games submitted by our members
Games in WIP (838)
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 ... 38
1  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3FX - A sneak peek on: 2018-03-12 23:34:15
Again, you cannot mix the two. On macOS, there's a single event loop that runs on the main thread (also has to be the first thread in the process).

First option is to have two windows created and managed by JavaFX, the first is covered by a canvas with OpenGL rendering on it, the second has a standard JavaFX stage. Second option is to have two windows created and managed by GLFW, both are typical GLFW/OpenGL windows, but the second uses JavaFX for rendering the stage. The first option is simpler to implement, the second would require translating GLFW events to JavaFX events to make the UI interactive, etc.
2  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3FX - A sneak peek on: 2018-03-12 20:18:28
I heard on Mac even this "co-existing" windows don't work...

Exactly, both JavaFX and GLFW have their own event loops and they don't know anything about each other. It's a conflict that cannot be resolved on macOS.

The plan is to offer two modes:

A. JavaFX + Glass are used as the windowing system (frames/input/etc). You're now able to do OpenGL rendering directly on a JavaFX node/canvas, without a performance hit. GLFW is not used in this case.
B. GLFW is used as the windowing system. You use the JavaFX rendering subsystem (Prism) to render a UI and/or 2D graphics to an FBO/texture. You use that texture however you like in your GLFW application. Glass is not used in this case.

The screenshots in the original post were made with a mode A solution.
3  Discussions / Miscellaneous Topics / Re: What I did today on: 2018-03-12 14:24:02
What do you mean you wouldn't use the opengl backend on windows?

bgfx defaults to using Direct3D 11 on Windows, but you can force it to use one of the D3D12/D3D9/GL/GLES backends. Vulkan will also be supported in the future. What I mean is that, given the choice, there's no good reason to prefer OpenGL on Windows over D3D/Vulkan.
4  Discussions / Miscellaneous Topics / Re: What I did today on: 2018-03-12 08:18:22
300 3D models.. all in shared buffers and they all use the same shader and same textures.. a large number of uniforms for controlling lighting

This is a very specific rendering scenario, it's anything but typical. I'd never expect bgfx to be useful to you, but not everyone does deferred/forward+ shading with hundreds of lights.

Because of that, the driver will create a full copy of the entire uniform buffer, including all the light data, giving each draw call its own version of the uniform buffer, with only the position offset actually differing between them.

I don't have a reason to dispute that, sounds reasonable. But also like something that a clever driver would trivially optimize (does it really have to use a single uniform buffer for everything internally?). Could you post a source that verifies the above?

aaaaand before you know it you have an inefficient as f**k behemoth that uses heuristics for which uniforms to place in which uniform buffers

Yeah, bgfx doesn't do anything like that internally, it's a fairly simple abstraction over the low-level rendering APIs. I wouldn't be surprised if graphics drivers used such heuristics though (see above).

by placing the data in a per-instance vertex attribute buffer

Yes, that's what bgfx does for instancing. That's also what I was doing ~10 years ago, back then UBOs/TBOs were generally a bad idea on all drivers/GPUs iirc.

Anyway, bgfx's developer has acknowledged that better support for UBOs is necessary and it's coming soon. There will be support for uniforms that are updated at different granularities (per-frame, per-view, per-draw), with the appropriate backend-specific implementations. Also, this all applies to Linux only, you wouldn't use the OpenGL backend on Windows/macOS (D3D11/12 & Metal respectively).
5  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LibGdx + IntellIJ + Mac OS = IllegalStateException: GLFW windows may only be cre on: 2018-03-11 15:13:52
Tried adding -XstartOnFirstThread as a VM argument in my run configuration, and the result was that the games launches, you hear the music for a second and then everything freezes and the window goes black.

Sounds like something is initializing AWT, which is not compatible with GLFW.

java.awt.headless thing didn't work. Get same error message.

It must be used in combination with -XstartOnFirstThread.

But the ideal solution would be to eliminate the AWT dependency. Do you use ImageIO, BufferedImage or anything like that?
6  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3FX - A sneak peek on: 2018-03-08 11:40:57
I have a fully-working Windows-only implementation ready in the LWJGLX/lwjgl3-awt Github repo, but Linux and MacOS support is still pending.

I suppose that some of the work could be shared. A cross-platform context management API/impl would be equally useful to both JavaFX and AWT/Swing. After that's done, implementing an AWT back-end similar to lwjgl2's should be simple. So, I don't mind doing that too, it's not a lot of work compared to what needs to be done for JavaFX.

The big difference is that AWT is set in stone, we're limited by what the JDK supports/allows. A JavaFX port opens up opportunities that will be impossible with AWT.
7  Discussions / Miscellaneous Topics / Re: What I did today on: 2018-03-07 23:04:22
So far, the most glaring missing feature is uniform buffers, instead using the old uniform system which has much worse performance than uniform buffers.

See #1231.

Secondly, it's unclear to what extent BGFX supports multithreading.

The build that ships with LWJGL supports up to 8 threads (the default) submitting draw calls. See the encoder API (bgfx_begin, bgfx_encoder_*).

Hence, if you expose an API that requires the user to provide all the data needed to run the API on Vulkan/DirectX12/Metal, adding support for anything older like OpenGL is trivial.

Apparently, after MoltenVK, Khronos will be working on Vulkan emulation libraries on top of Direct3D 12 and OpenGL. So, if anyone's planning to learn Vulkan seriously, eventually it will be a pretty good investment. If you don't have the time for that and just want to get robust results quickly, bgfx is a very good choice for targeting GL/D3D12/Metal.
8  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3FX - A sneak peek on: 2018-03-07 19:38:45
Oracle has announced that JavaFX and WebStart will not be available anymore, starting from Java 11 (September 2018, the next LTS release):

Java Client Roadmap Update

Also, an OpenJFX mirror is now available on github at javafxports/openjdk-jfx.

I would still very much prefer CEF+#1006, but I think this development will be good for JavaFX. It's also a good opportunity. No more hacking our way into the built-in JavaFX. The biggest technical hurdle is removed and we don't even have to worry about compatibility. You could bundle any JavaFX fork you like in your application, not only with a different backend, but also a different API (if necessary).

So, I'll probably resume work on LWJGL3FX in about 2-3 months. It will be a public fork, under the LWJGL organization on Github. If @KaiHH or anyone else would like to contribute, I'd be very happy to do this as a team effort. The initial plan:

- Refactor the GLES backend to use lwjgl3. It should work on Windows/Linux/macOS, at least.
- Eliminate the awkward native code paths and use Java/lwjgl3 for everything.
- Eliminate the hard-coded 1ms animation delay.
- Support both:
    * Render OpenGL views inside the JavaFX node hierarchy.
    * Render a JavaFX node hierarchy to texture, use texture in a GLFW+GL/Vulkan application.

If interested, please post here or contact me directly.
9  Discussions / General Discussions / Re: Vulkan Game Engine on: 2018-03-03 17:29:57
The first LWJGL 3.1.7 snapshot is now available with Vulkan 1.0.69 and MoltenVK. If you're on macOS, add this to your Maven script:


or equivalent for Gradle/Ivy, or get it from

A new binding has also been added: the Vulkan Memory Allocator (lwjgl-vma module). It simplifies CPU & GPU memory management of Vulkan applications.
10  Discussions / General Discussions / Re: Vulkan Game Engine on: 2018-02-26 14:51:27
MoltenVK has been open-sourced, macOS is now a fully supported platform for Vulkan applications.
11  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Universal Model Importer (JUMI) - Early Alpha on: 2018-02-23 08:53:56
So are you generating the bindings, like with GlueGen or something?

Yes, using a custom generator, written in Kotlin.

The Assimp project is very active, so it is recommended to stay with the LWJGL nightly/snapshot builds if you use it. You'll get the latest updates more regularly that way.

Btw, elect not only develops kotlin-graphics/assimp, he also contributes fixes upstream to the native project. Which is awesome and the kind of thing I really appreciate in OSS development.
12  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java Universal Model Importer (JUMI) - Early Alpha on: 2018-02-22 20:28:57
Support for .fbx export is currently in progress. Btw, LWJGL 3 provides native Assimp bindings.

Might be interesting to some, looks like glTF 2 (also supported by Assimp) is picking up steam:

Godot - Why We Should All Support glTF 2.0
Facebook - Richer 3D Posts
13  Discussions / General Discussions / Re: Vulkan Game Engine on: 2018-02-22 16:03:28
Just to be clear, I can't wait for value types for normal Java code. It's incredibly exciting, considering that we'll also get generics with value specializations (List<int> anyone?). But they won't do much for native interop. We need Project Panama for that.

The interesting thing is that compute heavy stuff like particle systems also need Project Panama. Removing object header overhead and pointer indirections is cool. SIMD vectorization for 7-8x speedups is much cooler. Automatic vectorization is not cutting it, there are so many annoying limitations, even on latest Java 10 builds.
14  Discussions / General Discussions / Re: Vulkan Game Engine on: 2018-02-22 15:53:51
There's no manual serialization in the classic serialization sense. That's just how the Vulkan API works. Instead of many functions with many parameters like in OpenGL, you have fewer functions and many structs (literally hundreds of them). You fill the struct members, you pass it to a function (that's why EA works well).

Value types won't change anything in the API. The JVM won't need to do EA for performance and maybe my life as a library maintainer will be easier, that's all.
15  Discussions / General Discussions / Re: Vulkan Game Engine on: 2018-02-22 15:26:14
Java is always going to be horribly hobbled by its objects model and buffer IO.

This would be true with typical JNI bindings. LWJGL bindings are not typical. This is what Vulkan code that runs at 5000fps looks like with LWJGL:

See those crossed out lines? They are Java allocations that have been eliminated with escape analysis. After scalar replacement, all that remains in the JITed code is a pointer address. Here's the list of eliminations in the entire hot path:

It is possible to write high performance Vulkan applications with LWJGL, with no Java allocations (escape analysis) and no native allocations (MemoryStack "allocations" are simple pointer additions/subtractions). In fact, almost every major decision that has shaped lwjgl3's API and internals, has been made to support writing and running Vulkan code efficiently.
16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3.1.6 on: 2018-02-04 20:43:33
So is the yoga issue all fixed then?

Yes, the yoga bug has been fixed (upstream too). The updated jemalloc build has also resolved what was triggering the crashes because of that bug.
17  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.6 on: 2018-02-04 18:15:56
LWJGL 3.1.6 has been released!

Release notes (JSR 305 nullability annotations, more Java 9 improvements, all bindings updated to latest versions)
18  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3.1.5 on: 2018-01-06 18:14:52
site refuses to download zip when JOML is selected

Fixed, thanks!
19  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-12-27 20:29:11
@Spasi: Programs that use GPU tend to be GPU bound.

Not sure what you mean. I'm talking about running OpenCL on the CPU, doing CPU work. Either because it's not GPU friendly or the payload is too small to be worth the CPU/GPU transfer overhead. Both Intel's and AMD's runtimes are mature and do fantastic vectorization.

This has actually been my motivation for maintaining the OpenCL bindings: enabling Java developers to easily write cross-platform SIMD programs. GPU applications are usually best served by GL/Vulkan compute or CUDA.
20  Game Development / Newbie & Debugging Questions / Re: LWJGL 3: loading HDR textures with StbImage in LWJGL 3? on: 2017-12-23 13:47:35
Would this be a good start?

Yes, that's the easiest solution on Windows & Linux. If you're on macOS, you'll have to check for OpenGL errors manually (glGetError()).
21  Game Development / Newbie & Debugging Questions / Re: LWJGL 3: loading HDR textures with StbImage in LWJGL 3? on: 2017-12-23 12:13:43
You're creating and sampling a 2D texture, but you're binding a GL_TEXTURE_CUBE_MAP when rendering. Are you sure no OpenGL errors are raised? Try creating a debug context and registering a debug callback to make sure.
22  Discussions / Miscellaneous Topics / Re: What I did today on: 2017-12-22 15:10:59

What a waste of time reinventing an inferior OpenCL running on the CPU. You could do this in LWJGL since 2010.
23  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 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.
24  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.
25  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?
26  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).
27  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.
28  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!
29  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

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!
30  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?
Pages: [1] 2 3 ... 38
Solater (14 views)
2018-03-17 05:04:08

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

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

buddyBro (101 views)
2018-02-28 16:59:18

buddyBro (56 views)
2018-02-28 16:45:17

xxMrPHDxx (467 views)
2017-12-31 17:17:51

xxMrPHDxx (141 views)
2017-12-31 17:15:51

xxMrPHDxx (217 views)
2017-12-28 18:11:33

Ecumene (492 views)
2017-09-30 02:57:34

theagentd (598 views)
2017-09-26 18:23:31
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!