Java-Gaming.org 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 3 ... 38
1  Game Development / Newbie & Debugging Questions / Re: Stubbornly insisting on using JLINK for deployment on: 2018-05-22 09:18:19
since JLINK creates a .bat not an .exe; (b) figured out how to keep the command shells minimized.

Isn't there a way to alter the script so that the console window closes as soon as the JVM is up?

I forgot to mention that we don't use the .bat/.sh script that jlink generates. It's very minimal and there's basically no way to make jlink generate anything interesting in it (e.g. you'd need to manually edit to set JLINK_VM_OPTIONS). The service launcher just runs the java executable with the appropriate arguments.
2  Game Development / Newbie & Debugging Questions / Re: Stubbornly insisting on using JLINK for deployment on: 2018-05-16 19:37:27
If you have another preference, would like to hear about it.

We're using jlink, compressing the result, then deploying that to servers, so I don't have experience with installers. But I know there are plenty of (free & commercial) options you could try.

Can I ask what the JSON file you have for srcfiles consists of?

Nothing special, just some settings for the application. It was a test to see how you may add random files to a bundle, in addition to the modular stuff.

Did you try this exact ordering? (I'm guessing you did, but on the off chance this might still be relevant...)

The problem is that javapackager does not call jlink (the cli command) internally, it uses the jlink API directly. The user arguments to jlink are supposed to be a key/value map, but parsing is broken somehow and you can effectively pass a single argument only.
3  Game Development / Newbie & Debugging Questions / Re: Stubbornly insisting on using JLINK for deployment on: 2018-05-16 11:49:58
This works for me:

Quote
"%JAVA_HOME%\bin\javapackager" ^
-deploy ^
-native exe ^
-outdir RELEASE ^
-srcdir . ^
-srcfiles config.json ^
--module-path target/modules ^
--add-modules java.management,jdk.naming.dns,java.security.jgss ^
--module net.webhotelier.avl/net.webhotelier.avl.Main ^
-name "WHJA" ^
-vendor "WebHotelier" ^
-v ^
-BjlinkOptions="compress=2"

I get a WHJA-1.0.exe in the RELEASE folder, which is a native Windows installer. When installed, the app folder contains config.json & WHJA.cfg, the runtime folder contains the jlinked runtime.

I wasted too much time on this and it feels like javapackager and jlink are not integrated as well as they ought to. The issues I have identified:

1. javapackager's --module-path acts weirdly. I had to put all modular jars in the same directory for it to work. With jlink I can mix directories & individual jars in the same path without problems.
2. I had to use the undocumented -BjlinkOptions to get a jlink minimized image. Without it I get a smaller installer (~18MB), but the installed application contains all modules (~107MB total). With compress=2, I get a bigger installer (~37MB), but the installed application contains only the modules necessary (~51MB total).
3. It's impossible to pass multiple jlink options (e.g. both --compress=2 and --no-header-files). Had a look at the source and it looks like a bug in javapackager's argument parsing.

If I were you, I'd use jlink directly and bundle the resulting image with a third-party solution to create the native installers/executables. Note that the Java Packager tool has always been part of JavaFX, which means a) don't expect software quality excellence and b) its future is questionable.
4  Game Development / Newbie & Debugging Questions / Re: Deploying a Java game on Steam on: 2018-04-22 10:16:11
We started using jlink'ed images in production a few months before Java 9 was released, they're convenient and work great. One problem is that all dependencies must be modular. Having an Automatic-Module-Name in the manifest is not enough, all JAR files must include a module-info.class with appropriate declarations.

A relatively easy solution to this is the ModiTect plugin for Maven. It injects module-info.class in your non-modular JAR files automatically, but the module descriptors must be written by hand. It can become annoying if dependencies use reflection a lot, but it's usually straightforward.
5  Discussions / General Discussions / Re: Vulkan Game Engine on: 2018-03-26 14:57:27
This looks interesting: V-EZ. More information: V-EZ brings "Easy Mode" to Vulkan
6  Discussions / General Discussions / Re: LWJGL Vulkan on Mac OS X on: 2018-03-26 10:58:11
That's what the console spits out:
1  
[LWJGL]     OS: Mac OS X v10.10.5

MoltenVK requires macOS 10.11 or later. You're on 10.10, so that's the biggest issue.

1  
[LWJGL] Loading library: MoltenVK

This line here, without further output, means that the LWJGL shared library loader was able to find the MoltenVK binary in natives/mac, but loading failed (because of the macOS version). LWJGL currently silently captures the error and moves on to try loading libvulkan.1.dylib, if available on the system. In a future LWJGL build, I'll make sure there's some useful output in this case.

That not-finding but seemingly still loading of lubvulkan.1.dylib is strange.
1  
2  
[LWJGL]    libvulkan.1.dylib not found in system paths
[LWJGL]    Loaded from java.library.path: natives/mac/libvulkan.1.dylib

This works as intended. Sometimes it's very useful to know on which paths the shared library was NOT found, before trying other paths. In this case, libvulkan.1.dylib is not a library bundled with LWJGL, so the system paths are examined first.

Important note: libvulkan.1.dylib is just the Vulkan ICD loader. It's a library that discovers Vulkan drivers in your system. Loading it on its own is not enough without libMoltenVK.dylib. This is why LWJGL bundles libMoltenVK.dylib directly. It's also more efficient, because it avoids an extra indirection on each Vulkan function call (see Best Application Performance Setup for details).

What happens in your case is this:

- LWJGL finds libMoltenVK.dylib in natives/mac, tries to load it and fails (the error is suppressed).
- LWJGL finds libvulkan.1.dylib in natives/mac, loads it successfully and configures GLFW to load it from there.
- GLFW loads the Vulkan loader, but the loader cannot find a working ICD, so you get the failed to find list of required Vulkan extensions error.
7  Discussions / General Discussions / Re: LWJGL Vulkan on Mac OS X on: 2018-03-25 20:34:34
.dylib files that came with the LWJGL download

Are you sure libMoltenVK.dylib is in there? What's the output if you run the program with -Dorg.lwjgl.util.Debug=true -Dorg.lwjgl.util.DebugLoader=true?
8  Discussions / General Discussions / Re: LWJGL Vulkan on Mac OS X on: 2018-03-25 15:53:21
the warning that libvulkan.1.dylib was missing

LWJGL's MoltenVK binary is probably missing from your module/class-path. You can get it via Maven with:

<dependency>
   <groupId>org.lwjgl</groupId>
   <artifactId>lwjgl-vulkan</artifactId>
   <version>3.1.7-SNAPSHOT</version>
   <classifier>natives-macos</classifier>
</dependency>

or equivalent for Gradle/Ivy, or get it from the LWJGL website.

Failed to find list of required Vulkan extensions

This means that GLFW cannot find the Vulkan binary. Make sure libvulkan.1.dylib is in a location where dlopen can find it. If you use the above LWJGL artifact you don't have to worry about it, GLFW will find it automatically.
9  Java Game APIs & Engines / OpenGL Development / Re: LWJGL stb bindings on: 2018-03-23 19:36:54
Thanks, fixed.
10  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.
11  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.
12  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.
13  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).
14  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?
15  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.
16  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.
17  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.
18  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:

1  
<dependency><groupId>org.lwjgl</groupId><artifactId>lwjgl-vulkan</artifactId><version>3.1.7-SNAPSHOT</version><classifier>natives-macos</classifier></dependency>


or equivalent for Gradle/Ivy, or get it from lwjgl.org.

A new binding has also been added: the Vulkan Memory Allocator (lwjgl-vma module). It simplifies CPU & GPU memory management of Vulkan applications.
19  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.
20  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.
21  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
22  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.
23  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.
24  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.
25  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.
26  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)
Download
27  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!
28  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.
29  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()).
30  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.
Pages: [1] 2 3 ... 38
 
DesertCoockie (53 views)
2018-05-13 18:23:11

nelsongames (85 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 (91 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 (186 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
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!