Java-Gaming.org Hi !
Featured games (85)
games approved by the League of Dukes
Games in Showcase (611)
Games in Android Showcase (172)
games submitted by our members
Games in WIP (657)
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 ... 30
1  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-27 17:58:54
CopyableCougar4, the title of your thread is a bit misleading as your problem is specific to one version of a set of Java bindings that supports OpenAL.

After all these years, aren't you f**king tired already? Do you really gain anything from bashing LWJGL all the time?

It's an open-source project. The source is here. All binary dependencies are built from source, you can find it here. If you think there's something wrong/buggy/evil about any of the above, you're welcome to submit a pull request. You won't catch a disease.

There is no corporation behind LWJGL. I have personally written most of the code. Is there something about me that you feel uncomfortable about and would like to discuss?
2  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-08-25 10:10:40
So it would be probably hundreds of small changes which produce identical native code.

That's OK. The useful metric isn't "how many line changes in the PR", but "how easy it is for the project owner to review the PR".
3  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-08-25 08:27:09
How would you feel about me doing a series of "Golden Axe of Refactorization" push requests?  With an explanation of each?

To anyone thinking about contributing to an open source project:

Just do it, you don't have to ask.

You'll feel better and the project owner will feel better. A pull request is a clean, fast and simple way to contribute. Even if it gets rejected, the discussion under the PR will be useful. You don't have to commit too much time either. Even if you've got big ideas, it's generally best to submit contributions in small batches.
4  Java Game APIs & Engines / OpenGL Development / Re: LWJGL jemalloc bindings on: 2015-08-22 23:18:17
Will the BufferUtils.createByteBuffer method make use of it?

The latest build (3.0.0b #19) includes an explicit memory management API in MemoryUtil. BufferUtils has not changed, works as before with GCed off-heap memory. Functions supported:

- memAlloc, memAlloc<Type>
- memCalloc, memCalloc<Type>
- memRealloc
- memFree
- memAlignedAlloc
- memAlignedFree

These map to the corresponding jemalloc functions by default. If jemalloc is not available, the standard stdlib.h functions will be used (memAlignAlloc maps to _aligned_malloc on Windows and posix_memalign on Linux/OS X).

LWJGL uses these functions internally, where it makes sense. Build #19 also includes important fixes and performance improvements.
5  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-08-16 22:59:03
Also, maybe we can have guards/branches that first test whether the approximation is applicable - the angle being in [0..PI/2]

The approximation is always applicable, by definition: "Both parameters to the arc tangent function are always positive". That is, omega is always an angle in the first quadrant.
6  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-08-16 22:38:57
Sure: http://pastebin.java-gaming.org/8d63d9f28331f

You should be able to use slerpOptimized in JOML as is, just rename the variables to match the original and remove the C-style declarations at the top (hate that).

The approximated version should have decent quality, but I'm not sure if/how you want it in JOML.
7  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-08-16 22:18:24
I actually appreciate Roquen's attempt to get people thinking. I've had him highlighted since Riven implemented that feature, he always has something interesting to say. But yes, his short/vague replies can be frustrating many times.

Anyway, I'm a practical guy and don't have time for derivations. What Roquen's replies made me think was: if there's anything interesting to be said about slerp, someone has said it already. So I used google: Understanding Slerp, Then Not Using It and Slerping Clock Cycles were the interesting hits. Everything you need to know about slerp is in there.

I ported the id code to Java. First of all JOML has a bug: it doesn't check the dot sign and doesn't flip the second sine based on that. This results in interpolation in the wrong direction (not the shortest one). Benchmark results (ns/slerp):

1  
2  
3  
4  
JOML: 324ns
  id: 363ns (reference)
  id: 149ns (optimized)
  id:  47ns (approximated)
8  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-15 21:36:00
This is all I do to create the OpenAL context:
1  
context = ALContext.create();

Yes, but if that alone works fine, then it must be some interaction with what your application (or We Shall Wake) is doing. I cannot figure this out without some code to test. Also, does the ALSOFT_LOGLEVEL output look any different when it locks up?
9  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-15 21:03:07
If it has never locked up on its own and it only happens in your app, then I don't think I can help more without a code sample that reproduces the issue. Could you please provide one?
10  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-15 20:39:51
It uses the mmdevapi, so the fix I did shouldn't have changed anything for you. Are you sure build #15 has fixed the issue?
11  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-15 06:00:45
And just to double check, is this the way you want me to set the log level?
1  
System.setProperty("ALSOFT_LOGLEVEL", "3");

No, it must be an environment variable. You can do
set ALSOFT_LOGLEVEL=3
at the command line before running your app. You should be getting a lot of output in stderr if you enable it correctly.
12  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-14 21:07:11
Build 3.0.0b #15 is up, it has the updated OpenAL.
13  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-14 17:20:26
I vaguely remember that post too and think the one being referred to is here.

A lot has changed since then and it might be that its been fixed in OpenAL-Soft now, although it looks like the code being referred to is still there.

Thanks. I was able to reproduce this with ALSOFT_DRIVERS=dsound (default is mmdevapi on my machine). Fixed it by patching OpenAL-Soft to fall back to GetDesktopWindow() when GetForegroundWindow() returns NULL (this workaround is recommended by Microsoft). Will update the LWJGL build soon.

But I don't think it's related to CopyableCougar4's problem. It simply makes alcOpenDevice fail, not freeze/block.
14  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-14 08:32:48
I cannot reproduce this, will need more info.

I do recall OpenAL sits on top of DirectSound APIs which require the a window handle and such to be initialised properly before they themselves can get initialised - wasn't there some sort of hacky loop in LWJGL2 to sit and retry a few times until it worked?

Yeah I can verify what cas says, it was the case at least like 3 years ago. Havent tried it in a while if that has changed.

I can't find anything like that in LWJGL 2. Could you point me to a commit or forum post?

Both DLLs talk about missing files when I open them in Dependency Walker.

It seems that when I run the program that just creates the OpenAL context, it has worked every time I try it. However the creation locking up happens more often when I create the context along with the GLFW/OpenGL context.

The executor service is me giving up on the OpenAL context creation after two seconds.

Do you create the OpenAL context before or after GLFW?

Try this code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
long defaultDeviceSpecifier = ALC10.nalcGetString(
   NULL, ALC11.ALC_DEFAULT_ALL_DEVICES_SPECIFIER,
   ALC.getFunctionProvider().getFunctionAddress("alcGetString")
);
System.err.println("DEVICE SPECIFIER: " + memDecodeUTF8(defaultDeviceSpecifier));

long device = ALC10.nalcOpenDevice(
   defaultDeviceSpecifier,
   ALC.getFunctionProvider().getFunctionAddress("alcOpenDevice")
);
System.err.println("DEVICE: " + device);

if ( device != NULL )
   ALC10.nalcCloseDevice(
      device,
      ALC.getFunctionProvider().getFunctionAddress("alcCloseDevice")
   );

Use it on its own in a simple main(), and also in your app (where you normally create the ALContext and it freezes). Also set the environment variable ALSOFT_LOGLEVEL to 3 before running anything. What output do you get?
15  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-13 08:52:37
Open the LWJGL2 dll or LWJGL3 one?

Both. See if the one from 3 has a dependency that's missing. I want to see if the problem is with the dll (the one from 3 is a much newer build) or with something else.

If I rename the LWJGL2 native to 'OpenAL.dll' it runs, but it still locks up.

Yeah, should have mentioned this. OpenAL.dll is the x64 binary, OpenAL32.dll is the x86 one.

EDIT: The last few tries seem to work, but I don't know if that will continue.

EDIT 2: Still spotty, but I seem to have more luck when I run a program that is just this:
1  
2  
3  
public static void main(String[] args) {
    ALContext.create();
}

More luck? As in, does it always work?

Just noticed from the stacktrace above that OpenAL is initialized concurrently from inside an Executor. This could be the problem, LWJGL 3 has no synchronization*. Could you share some code that's similar to what you're doing (but much simpler, no dependencies to com.digiturtle.library please)?

* and probably never will, leaving this up to the user.
16  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-13 00:39:02
Try opening the dll in Dependency Walker (ignore any *-MS_WIN-*.DLL).
17  Discussions / Miscellaneous Topics / Re: OpenAL fails on my computer on: 2015-08-13 00:11:11
One thing you can try is replace OpenAL.dll in LWJGL 3 with the one from LWJGL 2. Does that fix the freezing? Btw, what is your operating system?
18  Java Game APIs & Engines / OpenGL Development / Re: LWJGL jemalloc bindings on: 2015-08-09 23:43:35
Hi, do you know when the javadoc will be up for this new set of bindings?

It's up now at http://javadoc.lwjgl.org/. The docs are uploaded at the same time as the build, but it takes a while for the index to update because of the CDN cache. I do not flush it for nightly builds.

I don't immediately see a use case for this in a typical opengl scenario because the render cycle shouldn't be creating ByteBuffer's ideally and this is where the time sensitive processing happens.  But in principal this sounds like something that could shave off time from a performance perspective for other use cases.

I'd be interested to hear where you think this could be used in LWJGL itself.

BufferUtils would be the most useful candidate, because it's used by everything else. But as I said, this can only be an opt-in. Other stuff that allocate:

- Callbacks. This should be easy to handle, they already have a destroy method.
- Structs. Some APIs use them a lot (Vulkan will too if it looks like Mantle) and it would be nice not having to worry about allocation overhead. This should be painless too. Structs currently can be used with either a ByteBuffer+static API or a typed struct instance (that wraps a ByteBuffer)+instance API. The struct class could be made Retainable and instances could allocate with jemalloc.
- Functions that encode CharSequences allocate (e.g. glShaderSource). These are just temporary ByteBuffers, they could be allocated and freed with jemalloc.
- Functions that decode Strings use the APIBuffer, which is an internal LWJGL class that provides temporary thread-local "stack" storage. It's super fast (faster than jemalloc), but if the string size is too big, it "stretches" the "stack" and that memory is never reclaimed. We could use jemalloc here too, speed is not an issue with such functions.
19  Java Game APIs & Engines / OpenGL Development / Re: LWJGL jemalloc bindings on: 2015-08-09 20:34:04
Could you give a short snippet (or a reference to some code) of how to use it?

Sure, it's quite simple:

1  
2  
3  
4  
5  
6  
7  
import static org.lwjgl.system.jemalloc.JEmalloc.*;
// ...
ByteBuffer buffer = je_malloc(1024);
FloatBuffer bones = je_calloc(80, 4 * 3 * 4).asFloatBuffer(); // 80 mat4x3
// ...
je_free(bones);
je_free(buffer);

This is just the basic usage. There are many other (standard and non-standard) methods and of course the unsafe/long versions that LWJGL generates.

Will the BufferUtils.createByteBuffer method make use of it?

Yes, I'll work on that soon. It's not trivial because I want to make it optional and using jemalloc requires explicit je_free calls to avoid leaking memory. Existing usages of BufferUtils do not have that requirement and will have to be adjusted accordingly.

Anyway, I haven't given it much thought yet. Today I wasted all my time porting the LWJGL CI travis scripts, from the old workers to the new container workers. So fast, so awesome! Smiley
20  Java Game APIs & Engines / OpenGL Development / LWJGL jemalloc bindings on: 2015-08-09 19:33:35
The latest LWJGL build (3.0.0b #12) includes jemalloc bindings; jemalloc is a general purpose malloc(3) implementation that emphasizes fragmentation avoidance and scalable concurrency support. It is widely used across the industry, read this post from Facebook Engineering for technical details. It is heavily configurable/tunable and includes monitoring/profiling tools.

Why should you care? Mainly because
ByteBuffer.allocateDirect
is expensive. The benefits of using jemalloc include:

- It's fast and cache friendly.
- It scales fantastically well with concurrent allocations.
- You can allocate without zeroing out the new memory. This is great if you know that you're going to write to the whole buffer, right after the allocation.
- It minimizes memory fragmentation.
- Has advanced features like aligned allocations, efficient reallocations, multiple allocation arenas, thread-local caches, etc.

One drawback is that you have to explicitly free the allocated memory.

I wrote a (synthetic/unrealistic) benchmark to compare it with the JDK allocator. It basically does 10 million buffer allocations/deallocations per thread. Results (all numbers are ns per allocation on a 3.1GHz Sandy Bridge):

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
22  
23  
// 8 bytes per buffer, 1 thread
     je_malloc :  74ns // no zeroing
     je_calloc :  79ns // zeroing
allocateDirect : 439ns // 5x slower

// 1024 bytes per buffer, 1 thread
     je_malloc :  74ns
     je_calloc : 114ns
allocateDirect : 577ns // 5x slower

// 8 bytes per buffer, 4 threads
     je_malloc :  19ns // awesome scaling
     je_calloc :  21ns
allocateDirect : n/a // took forever and I killed it, process memory at 2.5GB+

// 1024 bytes per buffer, 4 threads
     je_malloc :  19ns
     je_calloc :  31ns
allocateDirect : OOM (direct buffer memory)

// Reduced the workload to 1/10th the allocations, 4 threads
allocateDirect(8)    : 556ns // slower than 1 thread
allocateDirect(1024) : 653ns // with -XX:MaxDirectMemorySize=3g, OOM without

It would be interesting to see how it performs in a real application with lots of ByteBuffer allocations. Please post here if you try it out. I couldn't provide more interesting data because all my apps go to great lengths to reuse or eliminate ByteBuffer allocations. What's very interesting about jemalloc is that it's fast enough to use for temporary/"stack" allocations.

Currently jemalloc comes as an extra dll/so/dylib in the LWJGL distributable. It's quite a big library (compared to other memory allocators), 105kb - 226kb depending on the OS/arch. If you aren't interested in using it, just delete the binaries. LWJGL itself may make use of it internally, but I'll do it conditionally, only if the binaries are available.

Forum admins: should I post LWJGL topics in the Engines, Libraries and Tools board? More often than not, they don't have anything to do with OpenGL (and Vulkan is coming...). Feel free to move this one too, if you think it's a good idea.
21  Discussions / General Discussions / Re: Windows 10 on: 2015-08-07 13:39:02
Performance seems to have taken a huge hit, on 7 I could have a TON of programs open, and if I opened another it would open in a blink of an eye. On 10 if I open more than maybe four programs then I have to say bye to my performance.

Sounds like the same problem I was having, which I fixed by disabling the Superfetch service. You can verify it by the memory usage of the System process in the Task Manager. It was many hundred megabytes before, now it is 0.1 MB. You may have to restart after disabling the service for the memory to be released.
22  Game Development / Performance Tuning / Re: Disabling floating point denormals on: 2015-08-06 14:18:17
Oh and I keep forgetting.  These modes only effect operations in SIMD registers.  Any ops which HotStop ends up using x87 will not be effected.  I don't expect there to be much usage of x87, but I haven't examined this in a long time.

Did a bit of testing, x87 is only used on the x86 JVM with
-XX:UseSSE=0
. The x64 JVM always uses SSE.
23  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-08-05 19:27:13
Added OpenGL ES bindings to LWJGL 3. Getting close to a beta release now and it feels like a massive weight is off my shoulders.
24  Game Development / Performance Tuning / Re: Disabling floating point denormals on: 2015-08-03 06:13:56
But the whole point is that it stays enabled when you return, right?

Yes, the point is to have it stay enabled so that it works with the fp code the JVM runs, not just inside the JNI call.

So just for my (perhaps slow) understanding, does this mean you might have to set some non-standard flags on the JVM to stop it from enforcing default settings there? Or is it just a testing issue?

No, you don't have to set a flag, there's no such flag anyway. The JVM, at some point around Java 5, was restoring MXCSR with the value it expects after every single JNI call. Unfortunately changing MXCSR is a very expensive, serializing operation and it totally killed performance, so the JVM doesn't do it anymore. You can enable that behavior with
-XX:+RestoreMXCSROnJNICall
. Afaict, this flag resets MXCSR without even checking if it changed. Using
-Xcheck:jni
on the other hand does in fact check if the value changed, prints a warning, then resets MXCSR (or crashes on Linux Smiley). This is what was happening with the LWJGL tests.

So, indeed it's a testing issue. But people should be aware that they're going behind the JVM's back with this trick and only use it if absolutely necessary.
25  Game Development / Performance Tuning / Re: Disabling floating point denormals on: 2015-08-02 22:30:39
Yes, you're allowed to change MXCSR inside a JNI call, but you have to change it back before returning. Enabling FTZ and DAZ like above is against the JVM specs and likely to cause issues. But I don't think it's really that dangerous. The register has thread scope, it won't affect anything other than the thread in which you enable FTZ/DAZ.
26  Game Development / Performance Tuning / Re: Disabling floating point denormals on: 2015-08-02 21:17:45
Does it already work on Linux & Mac too?

It works on Mac too, but I found a case where it fails. I added a denormal test to the LWJGL test suite and it worked fine on Windows. But when I tried running it on Mac I got this warning:

Quote
MXCSR changed by native JNI code, use -XX:+RestoreMXCSROnJNICall

and the test failed. On Linux, it crashed (on a very different JVM version though). Searched a bit and the problem ended up being
-Xcheck:jni
used by the test suite. Without it, the test passes on all OSes. A good description of why this happens can be found here.
27  Game Development / Performance Tuning / Re: Disabling floating point denormals on: 2015-08-02 20:37:13
Can you clarify a little what this is useful for?

erikd explained it in his first post. Basically you can get hit by really bad performance if your fp math code encounters too many denormals. In his case it's quite common, but it might not be affecting other code at all. You can use this snippet to test for it:

1  
2  
3  
4  
5  
_MM_SET_EXCEPTION_STATE(0);
// ...fp math here...
if ( (_MM_GET_EXCEPTION_STATE() & _MM_EXCEPT_DENORM) != 0 ) {
   // above code underflows to denormal fp
}
28  Game Development / Performance Tuning / Re: Disabling floating point denormals on: 2015-08-02 20:29:38
It works on Linux. It compiled on Mac (on Travis CI) but I haven't tested yet.
29  Game Development / Performance Tuning / Re: Disabling floating point denormals on: 2015-08-02 11:28:56
The latest LWJGL build (3.0.0b #9) includes bindings to the SSE control register macros. Example code:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
import static org.lwjgl.system.simd.SSE.*;
import static org.lwjgl.system.simd.SSE3.*;

// ...

_MM_SET_EXCEPTION_STATE(0);
// ...fp math here...
if ( (_MM_GET_EXCEPTION_STATE() & _MM_EXCEPT_DENORM) != 0 ) {
   // above code underflows to denormal fp
}

// enable flush-to-zero and denormals-are-zero modes
_MM_SET_FLUSH_ZERO_MODE(_MM_FLUSH_ZERO_ON);
_MM_SET_DENORMALS_ZERO_MODE(_MM_DENORMALS_ZERO_ON);
30  Game Development / Performance Tuning / Re: Disabling floating point denormals on: 2015-08-01 21:56:31
The source code is there as well (as much as there is any); feel free to use it any way you like. If it's useful enough, maybe this should become a proper cross-platform library.

Thanks, I think I'll add this to LWJGL 3.
Pages: [1] 2 3 ... 30
 
GamerC4 (22 views)
2015-08-22 20:38:50

GamerC4 (20 views)
2015-08-22 20:37:18

GamerC4 (24 views)
2015-08-22 20:37:01

Kefwar (26 views)
2015-08-22 18:07:24

GamerC4 (23 views)
2015-08-22 01:00:24

GamerC4 (36 views)
2015-08-22 01:00:17

GamerC4 (22 views)
2015-08-22 00:57:35

GamerC4 (24 views)
2015-08-22 00:56:59

BurntPizza (29 views)
2015-08-21 01:38:01

KaiHH (43 views)
2015-08-19 15:01:05
Rendering resources
by Roquen
2015-08-17 12:42:29

Rendering resources
by Roquen
2015-08-17 09:36:56

Rendering resources
by Roquen
2015-08-13 07:40:51

Networking Resources
by Roquen
2015-08-13 07:40:43

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
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!