Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (601)
Games in Android Showcase (171)
games submitted by our members
Games in WIP (649)
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 ... 29
1  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-07-24 09:05:35
I understand your points and see where you're coming from, but I'm coming from the standpoint of how NIO was supposed to be used (ignoring Riven's distaste for it Grin).

NIO made so many new things possible when it was released (including LWJGL). But it also is just a plain bad API. I mean no disrespect to the people that wrote it, they did what they had to do at the time. I mostly blame the platform/industry that makes it so hard to fix/replace standard APIs.

There are many high-profile developers that are looking for a NIO replacement these days. Look for the sun.misc.Unsafe drama that's been unfolding recently (it's being hidden away in Java 9, without a complete replacement) and you'll find several references to why NIO needs a redesign.

Or did you refer to the optimization of less CPU registers being used as all the values wouldn't need to be stored in registers until they are all evaluated?

This. More info:

The optimized code (without the method call) needs a couple of registers to do the whole thing. But it's not massively faster than the alias-sensitive call. One would think that the method call pushes the arguments to 16 registers or the stack. But it's much better than that. The JIT does a fantastic job with reordering operations, such that it works correctly (when argument = dest) and also the registers required are as few as possible. IIRC it does the job in 5 registers, last time I checked. This is also the reason that using Unsafe (e.g. via LibStruct) does not result in better performance*: the JVM never reorders Unsafe accesses and the resulting code is suboptimal.

* pure CPU performance, ignoring the better cache utilization that LibStruct enables
2  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-07-23 16:21:03
The hell? What makes you think I was looking for trouble either for me as implementor or for users using JOML? As I see it, the current debate is also not so much about performance as it is about convenience and meeting a user's expectations.

Hey, I was trying to be funny. Tongue

I know how hard it is being bombarded with requests and suggestions when doing open-source work. I contributed to that with one more suggestion, which is more stuff for you to consider (=trouble). It had nothing to do with the current debate.
3  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-07-23 15:35:26
If you're looking for more trouble, you could also add "terminal" versions of the various methods that accept a Matrix4f dest. Using theagentd's earlier example:

1  
2  
matrix.translationRotateScale(...).mul(...).get(directBuffer); // get is the terminal operation
matrix.translationRotateScale(...).mul(..., directBuffer); // now mul is the terminal operation

The result of mul is stored in the buffer directly, which eliminates a copy and should result in better performance.
4  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-07-23 06:46:02
1 flip() after filing my buffer is better than continuously setting the position, and it is especially less error prone in case I add another get(buffer) in there in complex code and forget to adjust the position increment properly.

There's probably not a right answer here and comes down to personal opinion. My personal opinion is:

- Having to deal with flip() means having to mentally track two variables; position and limit. This is more complex than dealing with position() only.
- Having a method call mutate arguments (i.e. changing a buffer's current position) is fundamentally bad practice and bad API design. I don't know about you, but I can reason better about method calls that are free of side-effects and any mutations to my objects are explicit.
- Last but not least, I've spent 12 years of my life reading posts on the LWJGL forum about people forgetting to .flip() a buffer.

Ah you misunderstood me as you worded my intentions exactly. I did notice how this.m00 is read after dest.m00 has been set, which is why the conditional is there to make sure it's not written to before it is read again in the case the destination is the same as either operands. I wasn't arguing for the inlining, I was arguing that avoiding a function call by adding a branch is not worth it as the function call will most likely be inlined by Hotspot anyway.

I must still be misunderstanding you. As I explained above, you cannot use a method call there as that would lead to different semantics (and defeat the optimization).
5  Game Development / Shared Code / Re: embedding javaFX inside opengl on: 2015-07-22 19:53:49
I'm assuming you're projecting the JavaFX texture on a 3D surface then. In the same way, you could project a custom cursor texture, after rendering the JavaFX texture.
6  Game Development / Shared Code / Re: embedding javaFX inside opengl on: 2015-07-22 19:20:59
Have you tried GLFW cursor functions? I don't see why you would need to draw it in the texture.
7  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-07-22 10:26:58
- Why did you choose to not increment the buffer's position:
This was chosen to be compliant with how LWJGL is doing it. Since those methods are likely being used to get a Matrix4f into a ByteBuffer before uploading it to OpenGL, incrementing the buffer's position would require the client to do a rewind(), flip(), position(int), clear() on the buffer before handing it to a Java/OpenGL binding.

Ahh makes sense... although I did not like that design at all either Smiley

Note that all those increments, rewinds and flips do memory writes. They do have an unnecessary performance cost.

- Is a conditional really cheaper than calling 'dest.set(...)':
I honestly don't know. Smiley Maybe someone can try it out. Just did it this way, because it reads a little bit better in the case where dest != this.

Readability should be no excuse for adding a branch to critical code Smiley .... I'll write a small benchmark next time i have a chance although I expect the impact is minimal.

It's not about inlining. Besides, if you used dest.set(...), then there would be no difference between the two branches.

It's about semantics. With dest.set(...) you're ensuring that all arguments will be evaluated before any memory write happens in the destination. Even if the method call is inlined, this invariant will make it all the way to the JITed code. The conditional detects that there's no aliasing and the semantics can be different: note how this.m00 is read 3 times after dest.m00 has been written to. This results in more efficient code (less CPU registers required).

The increased bytecode size and the branch itself have a cost though, which may negate any benefits. It might be better to offer a version of mul with explicit no-aliasing semantics. The user would be responsible to use it when appropriate.
8  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-07-19 14:09:13
I see OpenCL a different field now which needs special treatment. The real motivating driving force for the library for me currently is easy porting of SSE intrinsics from GCC/msvc to Java.
A disadvantage of OpenCL in addition to what @Spasi already mentioned is for me: complexity in the writing of algorithms for it.
Remember that OpenCL conceptually (and with modern GPUs also physically) only has scalar operations.
Now to actually do SIMD, you would need to think about multithreading in a clever way to actually use 4 threads to simultaneously operate on a 4-component vector (or bigger).
And to have the best possible performance, those threads will likely want to be in the same wavefront and the data they access would need to be consecutive.
Also, the operational semantics and the concept of OpenCL are quite different from x86 SSE, though both provide SIMD.
If you want to think of SSE in terms of OpenCL, it would be that SSE only has 4 threads. Those 4 threads are synchronized "implicitly" after each SSE instruction. Each such instruction has lock semantics (meaning changes to memory are visible immediately) within the same thread group (those 4 threads).
In SSE you express your algorithm in SIMD form, whereas in OpenCL you express it in scalar form and hope that the runtime will execute multiple such instructions in parallel.
All in all this makes SSE a lot easier to use than OpenCL, but of course also limits you to 4 threads.
But if you want to use more than 4 "conceptual" threads you can of course always use operating system threads to parallelize your SSE algorithm even further on more data, so having "more" SIMD. Smiley

Everything you said here is wrong, you're missing the point of OpenCL entirely. Multithreading happens at the workgroup level. Everything within a workgroup runs on the same thread with appropriate SIMD instructions for the kernel workload and target CPU. Read this for details. The Intel OpenCL compiler can even output 512-bit SIMD on Xeon Phi.

You really cannot beat OpenCL in terms of usability either:

1  
2  
3  
float4 a = ...;
float4 b = ...;
float4 r = a + b; // it doesn't get more friendly than this


1  
2  
3  
float16 a = ...;
float16 b = ...;
float16 r = a + b; // this will be 1 instruction on Phi or 4 "unrolled" instructions with plain SSE

GPUs are indeed scalar these days. For example AMD cards had vector registers up to the Radeon HD 6000 series (VLIW5 originally, then VLIW4), but switched to a scalar architecture with GCN. A vec4 operation will indeed be translated to 4 scalar instructions, but that's an implementation detail. In both OpenGL shaders and OpenCL kernels, you're using vector types for the semantics; it is the compiler's job to translate that to the optimal hardware instructions. That means SIMD on Intel CPUs.
9  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-07-19 06:52:18
@Kai, assuming what you describe above is doable, you could then wrap the low-level interface in a user-friendly API similar to SIMD.js.

Would this cause some kind of JNI overhead?

It doesn't change anything performance-wise, you'd still have to batch enough work to trivialize the native call overhead.

An advantage of the tool would be that noobs like me can use SSE without figuring out the vagaries of SSE on different architectures.
But would a disadvantage for the experts be that your tool would sacrifice some control so that the most efficient SSE code could not be made using java code?

What Kai is describing is direct access to SIMD instructions from Java. So full control and full performance. It doesn't make it any easier for people not familiar with SSE. But of course you could hide the nastiness in JOML or something like SIMD.js.

I wonder how fast SSE is compared to using OpenCL, as @Spasi hinted at above. Since most performance-intensive programs will use the graphics card, openCL would be available to them and might even be faster than SSE given the much larger amount of cores on graphics cards and the possibility of the openCL calculation results being kept on the graphics card for drawing in openGL.

The benefit of OpenCL is transparent use of SSE->AVX2 and multithreading at the same time. The disadvantages are a) you'd have to batch up more work, going through OpenCL will have more overhead than what Kai is doing and b) OpenCL availability; SSE is everywhere, but OpenCL requires a runtime to be available at the user's machine.

Also note that using the GPU with OpenCL is not an option in this case. I'm assuming that whatever you're doing with JOML needs to be CPU-accessible, for culling, collision-detection, etc. Otherwise, you'd be using OpenGL shaders directly.

10  Java Game APIs & Engines / OpenGL Development / Re: Embedding bits of OpenGL in JavaFX scene graph on: 2015-07-18 12:26:44
It's also boggling but predictable that they've not made an OpenGL backend available in the Windows distribution, nor any way to allow for hooks into the GL or DX context to make this sort of extension easy.

I've been looking at CEF as an alternative to JavaFX for rich interfaces. It has a nice C API and supports offscreen rendering, but looks like it has the same issue; no support for zero-copy or at least a GPU-to-GPU copy.
11  Java Game APIs & Engines / OpenGL Development / Re: Embedding bits of OpenGL in JavaFX scene graph on: 2015-07-18 00:13:06
This seems to work (unoptimized):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
ByteBuffer direct = ...
WritableImage writableImg = ...

// Get the platform image
Method getWritablePlatformImage = javafx.scene.image.Image.class.getDeclaredMethod("getWritablePlatformImage");
getWritablePlatformImage.setAccessible(true);
com.sun.prism.Image prismImg = (com.sun.prism.Image)getWritablePlatformImage.invoke(writableImg);

// Replace the buffer
Field pixelBuffer = com.sun.prism.Image.class.getDeclaredField("pixelBuffer");
pixelBuffer.setAccessible(true);
pixelBuffer.set(prismImg, direct);

// Invalidate the platform image
Field serial = com.sun.prism.Image.class.getDeclaredField("serial");
serial.setAccessible(true);
Array.setInt(serial.get(prismImg), 0, Array.getInt(serial.get(prismImg), 0) + 1);

// Invalidate the WritableImage
Method pixelsDirty = javafx.scene.image.Image.class.getDeclaredMethod("pixelsDirty");
pixelsDirty.setAccessible(true);
pixelsDirty.invoke(writableImg);

The benefit is quite small, 5-7% faster in my test.
12  Java Game APIs & Engines / OpenGL Development / Re: Embedding bits of OpenGL in JavaFX scene graph on: 2015-07-17 23:23:58
What's the prevailing wisdom on how to draw bits of the scenegraph using OpenGL?

See LWJGL-FX. It is a bit complicated because:

a) it does both OpenGL-in-JavaFX and JavaFX-in-OpenGL
b) it does asynchronous readbacks/uploads with double/triple-buffering for performance
c) it has multiple readback/upload implementations for optimal performance on different GPUs (AMD_pinned_memory on AMD, INTEL_map_texture on Intel for linear texture layouts, etc)

You could clean it up and keep only the stuff you need.

I've used some Unsafe hackery so that the "raw" array referred to there is actually being written directly into by glReadPixels, which I have to do because glReadPixels requires a direct ByteBuffer whereas setPixels only takes either a byte[] array or a heap ByteBuffer (irritating but not too hard to work around in the end). So that at least saves a fairly big copy.

LWJGL-FX uses the direct ByteBuffer in setPixels and it works fine. Why wouldn't it work? The WritableImage is indeed backed by a heap ByteBuffer and the copy goes through java.nio.Bits.copyToArray (it's an unsafe.copyMemory loop).

Is there a better (more efficient) way than this?

What happens now is:

- GPU to CPU readback (1st copy)
- Off-heap ByteBuffer to on-heap WritableImage (2nd copy)
- WritableImage to GPU upload (3rd copy, by JavaFX)

It should be possible to get rid of the 2nd copy, with unsafe/reflection hackery. Either replace the on-heap buffer with the off-heap one, or make the readback write directly to it (risky due to GC). That could be a decent win if the 3D scene is large enough, though the readback is probably the slower of the 3 copies.
13  Java Game APIs & Engines / OpenGL Development / Re: LWJGL stb bindings on: 2015-07-16 08:33:29
The latest nightly build includes an updated font rasterizer, as described here: How the stb_truetype Anti-Aliased Software Rasterizer v2 Works
14  Java Game APIs & Engines / OpenGL Development / Re: [LWJGL3] Experiencing weird crash on glUseProgram when started in fullscreen on: 2015-07-15 11:01:14
It crashes at glUseProgram, which could be a driver bug. Does it work with a simpler shader?
15  Java Game APIs & Engines / OpenGL Development / Re: [LWJGL3] Experiencing weird crash on glUseProgram when started in fullscreen on: 2015-07-15 10:55:33
Hard to say without the full log, but it seems to be crashing in the driver.
16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-07-14 17:56:34
Has anyone considered using OpenCL with a CPU device for this type of thing? What Kai is doing is basically compiling and running a simple OpenCL kernel.
17  Game Development / Newbie & Debugging Questions / Re: JNI threading > JNIEnv memleaks on: 2015-07-03 18:28:12
That's a bit of an arbitrary viewpoint, although it might be true for the majority of use cases with LWJGL.  Using a native media library for video inter-titles is one obvious case where it might not be though, as it's likely to start a new media callback thread each time.

Yes, it's arbitrary and one of the pending issues for 3.0. Current testing (even tried thousands of OpenCL native kernels that spawn several threads in the driver) has shown no measurable leaks, though different use cases may prove otherwise. I have implemented JNA's TLS cleanup, but I couldn't get it to trigger before JVM exit with the current LWJGL bindings.

Worked a bit more on this. Tested on an Nvidia GPU, still no luck. Funny how it spawns a silly amount of threads (with threaded optimization on in the driver settings) and never kills them. So, had to go to native code to manually spawn/attach/exit a native thread. You were right, I have now added automatic thread detaching to LWJGL.
18  Game Development / Shared Code / Re: embedding javaFX inside opengl on: 2015-07-01 20:31:32
I'm not. It is a proof of concept demo, from 3 years ago using LWJGL 2. It features both rendering JavaFX content in an OpenGL scene and rendering the OpenGL scene as a JavaFX node. It isn't something I'd use in a real application, so never bothered with event translation.
19  Game Development / Shared Code / Re: embedding javaFX inside opengl on: 2015-07-01 20:17:49
(you could subclass texupdater and use a PBO with a mapped bytebuffer too)

The org.lwjgl.util.stream package in LWJGL-FX contains a few implementations and supports buffering.
20  Java Game APIs & Engines / OpenGL Development / Re: LWJGL 3.0.0a on: 2015-07-01 20:13:50
With the help of @badlogicgames, the 3.0.0a release has been published to Sonatype/Maven Central. Nightly builds are now also published as snapshots. This demo project serves as a tutorial to get you started with either Maven or Gradle. Use "3.0.0b-SNAPSHOT" (not 'a') for the snapshot builds.
21  Java Game APIs & Engines / OpenGL Development / Re: LWJGL stb bindings on: 2015-07-01 08:13:21
Thanks, fixed.
22  Game Development / Newbie & Debugging Questions / Re: JNI threading > JNIEnv memleaks on: 2015-06-30 15:05:30
i'm a bit confused, my tests show that this method do not behave like that - but that's the same behaviour which occurs when the callback is executed form a "already attached" thread (not async).  even if i detach a attached thread, it seems not to dispose the java thread object and still reuse it on the next attach - that is not really possible when detaching purges the cache. so confusing.  persecutioncomplex

The debug output callbacks may be called asynchronously, but the spec does not enforce this as a requirement. For example, my AMD driver does not seem to support async callbacks, it behaves like GL_DEBUG_OUTPUT_SYNCHRONOUS is always enabled. So, the native thread is a Java thread and Attach/Detach don't really do anything. This may be what you're seeing; try printing the thread id to verify.

But not AFAIK automatic thread detachment using TLS destructors, or a least it didn't, which is a shame!

Indeed, it does not detach threads automatically.

That's a bit of an arbitrary viewpoint, although it might be true for the majority of use cases with LWJGL.  Using a native media library for video inter-titles is one obvious case where it might not be though, as it's likely to start a new media callback thread each time.

Yes, it's arbitrary and one of the pending issues for 3.0. Current testing (even tried thousands of OpenCL native kernels that spawn several threads in the driver) has shown no measurable leaks, though different use cases may prove otherwise. I have implemented JNA's TLS cleanup, but I couldn't get it to trigger before JVM exit with the current LWJGL bindings.
23  Game Development / Newbie & Debugging Questions / Re: JNI threading > JNIEnv memleaks on: 2015-06-30 12:22:21
ARB_debug_output and KHR_debug by default support asynchronous callback invocations. That is why LWJGL 2 uses Attach/Detach. You can also glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS) which will force debug output to run on the same thread that invoked the OpenGL function that caused the error (before that function returns). This obviously has a performance impact, but is probably acceptable for debug functionality.

LWJGL 3 uses the same code for all callbacks (via libffi). Since a callback can be either synchronous or asynchronous, GetEnv is first used, then AttachCurrentThreadAsDaemon. The result is stored in thread-local-storage, like JNA, and subsequent invocations use that. This avoids some minor overhead from calling into the JVM. DetachCurrentThread is never called; the expectation is that native threads will be few and as long-lived as the application.

AttachCurrentThread (source) is expensive. If you call DetachCurrentThread on every invocation, you will pay that price every time (about 100 microseconds on my machine). The good news is that the JVM uses TLS caching too; multiple calls to AttachCurrentThread will be cheap. There is no reference counting, a single DetachCurrentThread will purge the cache.
24  Java Game APIs & Engines / OpenGL Development / Re: [LWJGL] Java 8 Dependency? Or is it just me? on: 2015-06-22 10:03:19
I can confirm that LWJGL 3 is compatible with Java 6 and up. It also builds fine on Java 6, including the generator.

the output is Java 6 compatible (for some reason - it may as well be Java 7 at least)

This is a recent discussion on why LWJGL 3 requires Java 6 (and not 5 or 7).
25  Game Development / Newbie & Debugging Questions / Re: Fonts in LWJGL on: 2015-06-12 15:57:04
I tried using the built-in TrueType class, but it seems to only allow loading fonts that are installed on the target system? Not from a location in the runtime path?

Not sure what you mean. You can load a .ttf file into a ByteBuffer any way you like, then use it with the TrueType class. This demo might help.
26  Game Development / Newbie & Debugging Questions / Re: glfwSetInputMode with GLFW_CURSOR breaks on linux on: 2015-06-02 08:11:45
I cannot reproduce this on Windows 8.1 or OpenSUSE 13.2.
27  Java Game APIs & Engines / Java Sound & OpenAL / Re: Does any1 know any good LWJGL3 OpenAL library? on: 2015-05-30 14:56:31
Btw, would you happen to know what this means?
1  
AL lib: (EE) UpdateDeviceParams: Failed to set 44100hz, got 48000hz instead

I don't know very accurately, but 44100Hz is the quality of Audio CDs. It is 44800Hz for DVDs, that message essentially means you have better hardware that can play more quality audio than you requested. It is the frequency of the sound I think.

I have pushed a change for this (build #50), the default ALContext creation will not try to override the device's ALC_FREQUENCY (or ALC_REFRESH). You shouldn't see this message anymore.
28  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-05-28 09:05:38
Do you mean what I said above about the bindings? That's tedious indeed. Once the bindings are in place though, wrapping the raw API in something higher level is simple. Then you can use it easily without having to worry about pointers and buffers and low-level details, like we do with OpenGL.
29  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-05-28 08:37:39
CPU cycles are rarely anything anyone needs to be concerned about concerning JDBC as the bottleneck is always somewhere else that you have no control over.

The problem is not burning CPU cycles to do useful work. The problem is wasting CPU cycles on cache misses, garbage collections and unnecessary thread synchronization. We're not in the 00's anymore; multi-gigabit network connections, in-memory databases, SSDs, everything is now at a microsecond level and you can't do anything with JDBC without millisecond spikes.

FWIW I use to use ODBC years and years ago in another life and ... it's not really significantly better than JDBC quite often, and of course, it's Windows only and impossible to debug when it does go wrong...

There are ODBC drivers on Linux, even for SQL Server. API-wise, obviously it's harder to use than JDBC, but can easily be wrapped in a Java-friendly way.
30  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-05-28 08:11:08
On FFI - anyone paying attention to how this is going? http://openjdk.java.net/projects/panama/

They're working on a Layout Descriptor Language.
Pages: [1] 2 3 ... 29
 
Riven (28 views)
2015-07-27 16:38:00

Riven (16 views)
2015-07-27 15:35:20

Riven (20 views)
2015-07-27 12:26:13

Riven (10 views)
2015-07-27 12:23:39

BurntPizza (27 views)
2015-07-25 00:14:37

BurntPizza (39 views)
2015-07-24 22:06:39

BurntPizza (22 views)
2015-07-24 06:06:53

NoxInc (25 views)
2015-07-22 22:16:53

NoxInc (17 views)
2015-07-22 22:13:39

Jesse (39 views)
2015-07-22 03:10:36
List of Learning Resources
by gouessej
2015-07-09 11:29:36

How Do I Expand My Game?
by bashfrog
2015-06-14 11:34:43

List of Learning Resources
by PocketCrafter7
2015-05-31 05:37:30

Intersection Methods
by Roquen
2015-05-29 08:19:33

List of Learning Resources
by SilverTiger
2015-05-05 10:20:32

How to: JGO Wiki
by Mac70
2015-02-17 20:56:16

2D Dynamic Lighting
by ThePixelPony
2015-01-01 20:25:42

How do I start Java Game Development?
by gouessej
2014-12-27 19:41:21
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!