Java-Gaming.org Hi !
Featured games (87)
games approved by the League of Dukes
Games in Showcase (649)
Games in Android Showcase (181)
games submitted by our members
Games in WIP (699)
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 ... 32
1  Game Development / Game Mechanics / Re: Best data structure for triangle collision meshes on: 2016-01-21 11:15:05
It seems like the biggest problem right now is that simply traversing the quad tree is very slow. Finding an alternative data structure sounds like a good idea.

Before trying something entirely new, it might be worth optimizing the current structure. My favorite information on the subject is Pitfalls of Object Oriented Programming. Not entirely possible in Java (until we get something like "packed arrays" in Java 10+), but the idea still applies. If you allocate all node data per tree level in one batch, most likely they will end up contiguous in memory. The two Java-specific problems here are a) GC moving the objects around (though that will be done in "batches" too) and b) the object header overhead. Both can be solved with off-heap data, via NIO buffers or a struct framework, but that sacrifices a bit of computation performance (many optimizations are coming in Java 9 that might change this).
2  Java Game APIs & Engines / OpenGL Development / Re: Massive internal JEmalloc/Nvidia driver memory leak? on: 2016-01-05 18:06:57
Did you try Configuration.MEMORY_ALLOCATOR.set("system") to make sure this has nothing to do with jemalloc?
3  Java Game APIs & Engines / OpenGL Development / Re: Massive internal JEmalloc/Nvidia driver memory leak? on: 2016-01-04 15:41:52
Could you please try this jemalloc build? It includes this fix, which sounds relevant to what you're describing.
4  Java Game APIs & Engines / OpenGL Development / Re: Massive internal JEmalloc/Nvidia driver memory leak? on: 2016-01-04 14:57:32
Note that the OutOfMemoryError is thrown by my own code when je_malloc() returns 0.

Do you use jemalloc directly? The debug allocator only tracks memory allocated via MemoryUtil (memAlloc(), memFree(), etc). Another advantage of using MemoryUtil is that you can easily switch to a different allocator with the Configuration.MEMORY_ALLOCATOR option.
5  Java Game APIs & Engines / OpenGL Development / Re: LWJGL stb bindings on: 2015-12-28 01:47:25
Most of the examples for the TrueType usage seem to be using an outdated API that more closely resembles the C version.

There are functions in stb_truetype that can be used to render text in a few different ways. Which ones you use depends on the level of quality, performance and customization you're interested in. There's no outdated API afaik. The Truetype demo uses the simple stbtt_BakeFontBitmap/stbtt_GetBakedQuad and the TruetypeOversample demo uses the higher quality stbtt_PackFontRanges/stbtt_GetPackedQuad. Neither demo handles codepoint kerning (not all fonts come with kerning information), but it's easy to add.

Also it uses the fixed pipeline for drawing the quads.

The purpose of these demos is to provide sample usage of the stb_truetype API. How to best render the quads is a generic OpenGL question and not specific to font rendering. They're just simple quads with a position and a texcoord. The answer will depend on the application and how much caching (of character sequences) it is able to do.

Is there better documentation that I can find or better examples?

There's plenty of javadoc in the STBTruetype class. Also, reading this will be useful.
6  Game Development / Game Play & Game Design / Re: Is a Binaural Sound Engine in Java possible? on: 2015-12-26 18:48:01
LWJGL 3 comes with OpenAL Soft which supports binaural audio rendering. The nightly build also has support for the SOFT_HRTF extension.
7  Java Game APIs & Engines / Engines, Libraries and Tools / Re: NanoVG Crash on: 2015-12-25 08:59:48
Did you use nvgCreateFontMem to create the font? One thing that's not at all obvious in the NanoVG documentation is that the buffer you pass to that function must remain valid for as long as the font is used for rendering. Your code is crashing in nvgTextBounds because internally NanoVG tries to access the font data buffer.

I'll add this to the NanoVG javadoc soon.
8  Java Game APIs & Engines / OpenGL Development / Re: LWJGL jemalloc bindings on: 2015-12-21 18:12:21
The idea is to pass longs across inline boundaries and use ByteBuffers for safety/convenience inside. An inline boundary is anything that breaks inlining (and consequently, escape analysis), which includes: the caller is too big, the callee is too big, the callee is too deep, etc. This is application-specific and requires some analysis (use -XX:BCEATraceLevel=3), but in most cases a trivial refactoring is enough to fix problematic methods. Anyway, the point is that it doesn't have to be a single method that does this, the code may call other methods (and pass ByteBuffer instances to them) and escape analysis can still work.

Here's a simple example that shows what I mean. You want to go from:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
void root() {
   ByteBuffer buffer = memAlloc(1024);

   methodA(buffer); // buffer instance escapes
   methodThatEventuallyCallsMethodB(buffer); // buffer instance escapes

   memFree(buffer);
}

// not inlineable because too big
void methodA(ByteBuffer buffer) {
   // do stuff
}

// not inlineable because too deep
void methodB(ByteBuffer buffer) {
   // do stuff
}

to:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
15  
16  
17  
18  
19  
20  
21  
void root() {
   int capacity = 1024;
   long address = nmemAlloc(capacity);

   methodA(address, capacity);
   methodThatEventuallyCallsMethodB(address, capacity);

   nmemFree(address);
}

// not inlineable because too big
void methodA(long address, int capacity) {
   ByteBuffer buffer = memByteBuffer(address, capacity); // escape analysis eliminates the buffer instance
   // do stuff
}

// not inlineable because too deep
void methodB(long address, int capacity) {
   ByteBuffer buffer = memByteBuffer(address, capacity); // escape analysis eliminates the buffer instance
   // do stuff
}

The root method could of course be some code that stores the allocated memory block in a data structure, for future reference across frames, etc. When testing this, keep in mind that you may get some garbage at first, until the methods are hot enough and the JIT kicks-in.

Methods in MemoryUtil like memByteBuffer, as well as anything that instantiates Struct/StructBuffer classes in LWJGL 3, have been tuned to enable this. This work was done between the alpha and beta releases and has been tested extensively (e.g. with an experimental Java backend for NanoVG). The JVM does a fantastic job when you follow the rules and I think it's the best we can have until we get value types in Java 10.
9  Java Game APIs & Engines / OpenGL Development / Re: LWJGL jemalloc bindings on: 2015-12-21 08:28:18
Yes. There are unsafe versions of the jemalloc functions, as well as the allocator-agnostic API in MemoryUtil. Those work with raw pointer values (long) instead of wrapping them in ByteBuffer instances.

However, keep in mind that LWJGL creates ByteBuffer instances in such a way, that lets the JVM eliminate allocations via escape analysis. Hot methods that allocate on enter and free on exit will almost always produce no garbage and using the unsafe API won't make a difference.

10  Discussions / General Discussions / Re: AMD announces GPUOpen -- Open Source alternative to Nvidia's GameWorks on: 2015-12-16 00:10:09
Also, I have heard talk (perhaps incorrectly) that there are thoughts of a DX binding in LWJGL3, although I'd need Spasi to confirm and/or deny.

I'll probably add a DX12 binding after Vulkan. I won't bother with earlier versions, but won't say no to a contribution.
11  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - NanoVG bindings on: 2015-12-10 12:33:01
NV_path_rendering also claims to have some specific advantages wrt. accuracy of rendering (and goes to lengths to explain how everyone else's implementation is slightly broken in various ways).

NV_path_rendering does analytical computations on quadratic segments directly, with more complex segments (cubic and arcs) approximated to quadratic. It also does it per-sample according to the documentation. NanoVG tessellates everything to linear segments, so it quite likely suffers from numerical instabilities like other implementations. I don't think this matters much for game GUIs or other real-time scenarios, but it'll probably be an issue for arbitrary SVG rendering.

So I presume it's rasterised on the CPU somehow? (Not dug into the source, but the docs don't seem particularly forthcoming)

No, there's no rasterization, just tessellation. The C code feeds triangles to the shader, which are rendered in two passes (stencil, then cover), like NV_path_rendering.

There was a request to implement a NanoVG back-end using NV_path_rendering but it was rejected. See this reply.
12  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - NanoVG bindings on: 2015-12-10 01:58:23
How does it perform?

Haven't done much testing, other than porting the native demos. But it feels fast enough. The UI in the screenshot above is quite rich and only takes about a millisecond to render.

The API is verbose, like immediate mode rendering, but it batches commands internally and renders everything with a single shader.

What's it like compared to NV_path_rendering?

They should be similar feature-wise, can't say performance-wise. The obvious NanoVG advantage is that it works on all GPUs.
13  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3 - NanoVG bindings on: 2015-12-09 18:30:09
The latest LWJGL nightly build (3.0.0 #6) adds bindings to NanoVG. It looks like this:

14  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2015-12-05 10:50:22
Can I have a TL;DR of this? What are the potential gains of this?

The main benefit is that you don't need JVM intrinsics anymore. Anything that required an intrinsic before can now be done by anyone. It works with raw machine code, so you have access to everything the hardware provides, for example vector instructions or the x86 PAUSE instruction for spin loops. Single instructions are not a problem (the worst-case for JNI).

If this is not in the Java 9 change log I will be disappointed.  Tongue

Project Panama won't make it to Java 9, even with the delayed schedule.
15  Discussions / General Discussions / Re: Interesting proposals: Java 9 and beyond on: 2015-12-04 20:51:40
Early prototype of JVM support for arbitrary machine code loading and execution.
16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3.0.0b on: 2015-11-21 06:40:26
Thanks, fixed the code sample.
17  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.0.0b on: 2015-11-20 23:53:21
LWJGL 3.0.0b has been released!

Visit the download page to get it. You can also get it from Maven Central or this direct link.

Release notes:

  • The API is now considered stable. There were several API changes, especially to struct and callback classes.
  • Moved advanced functionality from the base package to the system package. Public API in the system package may change between releases.
  • Critical methods have been optimized for better performance and garbage elimination.
  • JNI methods are now deduplicated and struct layout is calculated in Java. This means much smaller shared libraries.
  • Introduced the Configuration class that can be used to programmatically configure LWJGL.
  • Introduced explicit memory management API, which is also used internally by LWJGL.
  • Introduced a debug allocator that can be enabled for the explicit memory management API. It reports memory leaks with full stack-traces to the leaked allocations.
  • All struct classes now have a corresponding StructBuffer implementation. Bindings now use Struct and StructBuffer parameters and return values, instead of ByteBuffer, which improves type safety.
  • Struct fields and accessors are now documented.
  • Many other fixes and minor features.

Changes to bindings:

  • Removed obsolete OS-specific bindings.
  • Added bindings to many OpenGL extensions that were missing in 3.0.0a.
  • Added bindings to jemalloc.
  • Added bindings to EGL.
  • Added bindings to OpenGL ES.
  • Added bindings to xxHash.
  • The bindings to LibOVR were updated to 0.8.0.0 and are now included in the official build.
  • Several other fixes and updates to existing bindings.
18  Game Development / Newbie & Debugging Questions / Re: [LWJGL] [GLFW] ImageIO.read stalling and glitching with GLFW use on: 2015-11-06 10:45:17
but could you explain to me/link me to another post explaining why AWT and GLFW cannot both be used simultaneously? Is there a conflict issue with the natives?

No, it has to do with fundamental issues in the design of OS X. There can be only one NSApplication instance and one main event loop that has to run in the main thread. In addition, the main thread must be the first thread in the process (that's why you need -XstartOnFirstThread). As you can imagine, both AWT and GLFW try to take over that first thread, that's why everything freezes when you try to use them together.
19  Game Development / Newbie & Debugging Questions / Re: [LWJGL] [GLFW] ImageIO.read stalling and glitching with GLFW use on: 2015-11-06 08:45:33
ImageIO depends on AWT and initializes it when you try to do anything. This means that you cannot use it with GLFW on OS X (for the same reasons you cannot use GLFW with AWT/Swing or JavaFX).

LWJGL 3 has bindings to stb_image from the stb library, see the STBImage class. It's as simple to use as ImageIO, supports common image formats (including HDR) and does some useful processing at load time (e.g. loading a 3-channel image as a 4-channel one).
20  Game Development / Newbie & Debugging Questions / Re: Placing a Swing JComponent inside an LWJGL Display on: 2015-10-24 19:12:53
a contributor has spent a lot of time in implementing an hardware accelerated pipeline for OpenJFX/JavaFX based on JOGL 2

We moved to a new home and will be without internet for a week or two. So, I got bored and decided to try this approach:



The JavaFX Ensemble application running on top of LWJGL without any custom native code.
21  Game Development / Newbie & Debugging Questions / Re: Best Way to Implement Music and Effects in Java 2D Game on: 2015-10-14 13:50:05
I'm a big fan of "just works".   Cool

Except the only sane way to distribute a Java application is with a private JRE included. I don't know anyone who doesn't do that. Who cares about Ubuntu and LTS. Is Ubuntu the only Linux distro out there?

With a private JRE and OpenAL-Soft binaries you also have a solution that just works, why is that different from JavaSound? (not comparing the low/high-level nature of the two APIs here)

On PortAudio, it is just one of 4-5 possible audio backends that OpenAL-Soft can use (at runtime). Considering the state of sound on Linux, I wouldn't ship an app without at least a few options. With that said, if you think using PortAudio directly would be beneficial, I wouldn't say no to an LWJGL binding if you've got time to contribute one.
22  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - API Freeze (request for feedback) on: 2015-10-12 12:13:23
Actually, it's possible to support both, i.e looking at the root and looking at /natives/<os.and.arch>/, which is what JogAmp does. It helps to produce a fat JAR of the libraries for the newbies (they just have to add a single JAR into the classpath and it works) and it helps to provide something easy to test anywhere (imagine "java -jar lwjgl-unit-tests.jar").

You can do this with LWJGL too. Put all binaries in a folder or inside a jar and it will work. The only difference is that with more OSes/architectures the LWJGL filenames will get uglier.

In my humble opinion, calling MemoryUtil.memFree() in PointerBuffer would make sense but it's a matter of taste.

Yes, but it would break the symmetry with NIO buffers, which don't have a free() method. I find symmetry more tasteful as a library designer.

As a user though, in my codebases that use LWJGL, I have added a free() method to all buffer classes via Kotlin extension functions.
23  Game Development / Newbie & Debugging Questions / Re: [LWJGL3] load natives next-to-jar on: 2015-10-12 11:44:36
That's why I don't generally recommend it. I added it to LWJGL mostly as a convenience for developers wanting to try the library via Maven/Gradle. Makes the first experience much nicer.
24  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - API Freeze (request for feedback) on: 2015-10-12 11:40:50
Why not supporting the same native libraries layout than JogAmp within a JAR? It would help to make a single cross-platform fat JAR or at least something supporting more than a single architecture:
http://jogamp.org/wiki/index.php/JogAmp_JAR_File_Handling#Usage

The idea consists in supporting such directories in which to look for the native libraries:
/natives/<os.and.arch>/

The initial design for LWJGL 3 was something like that. Unfortunately there were complains from several users that preferred a simpler structure, like in LWJGL 2. I personally preferred the subfolder structure, it was cleaner and didn't require adding ugly suffixes to shared libraries.

Keep in mind though that LWJGL doesn't care where the binaries come from. The artifacts are not signed (and never will be, it's your responsibility), you're free to change the existing structure, remove stuff you don't need, etc. All library paths and names are configurable at runtime, so in theory you could replicate JogAmp's design.

Why isn't possible to "free" a PointerBuffer directly?

It is possible, for PointerBuffers allocated via the native allocator. Use memFree() from the MemoryUtil class. The same applies to NIO buffers and StructBuffer implementations.

Do you provide a method to deallocate a direct NIO buffer constructed by Java itself and not by using malloc or jemalloc?

No. Users that care about efficient deallocation should already be using native allocation instead of Buffer.allocateDirect.

Please can you improve the Java documentation of the packages? It's a bit hard to understand the roles of the subpackages for a newbie, isn't it?

This is planned for after the 3.0.0b release. Among other things.
25  Game Development / Newbie & Debugging Questions / Re: [LWJGL3] load natives next-to-jar on: 2015-10-12 11:21:03
Does LWJGL 3 extract the native libraries from the JAR and copy them into a temporary directory before loading them?

Yes. The code for this was contributed by @badlogicgames.
26  Game Development / Newbie & Debugging Questions / Re: [LWJGL3] load natives next-to-jar on: 2015-10-12 10:32:48
Hey orange451,

With lwjgl2 I always liked to load my natives from a folder next to the jar file; it just seems nicer that way than having to specify a command-line. To do this, I wrote:
1  
System.setProperty("java.library.path", new File("Resources/native").getAbsolutePath());

In my main method.

The above could not have worked with LWJGL 2 either. The "java.library.path" property is read only once at JVM startup and cached. Effectively you cannot set it at runtime, without some hackery at least. That's why LWJGL 2 supported the "org.lwjgl.librarypath" property and LWJGL 3 does too.

Like kappa mentioned, LWJGL 3 now also has the Configuration class. It is just a nicer way to configure LWJGL programmatically, with appropriate documentation and without hard to remember strings.
27  Game Development / Shared Code / Re: Extremely Fast sine/cosine on: 2015-10-07 19:13:15
Results on MBP 2015 (3.1GHz Broadwell i7, JDK 8u40 x64)

1  
2  
3  
4  
5  
6  
// latest version
scalarRivenMath  2005.062 ± 122.597  us/op
sumOfAngles      2192.988 ± 404.607  us/op
// my sumOfAngles
scalarRivenMath  2024.594 ± 233.004  us/op
sumOfAngles      2031.853 ± 146.233  us/op

Disclaimer: I saw high variance between runs, which I attribute to CPU thermal throttling. Had to let the laptop cool down a bit before getting consistent results. This might be affecting you too.

The problem seems to be related to less efficient cache use on laptop CPUs. sumOfAngles becomes almost 40% faster with 1/10th the workload (N = 100_000).
28  Game Development / Shared Code / Re: Extremely Fast sine/cosine on: 2015-10-07 18:24:56
Using your latest version:

1  
2  
Test.scalarRivenMath 2970,533 us/op
Test.sumOfAngles     2346,007 us/op

Could I see your sumOfAngles implementation? I'm curious as to how fastMath and sumOfAngles switched places.

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
14  
public void sumOfAngles(PrecompState state) {
   state.t += 1 / 60f;
 
   float sint = Riven.sin(state.t);
   float cost = Riven.cos(state.t);
   for (int i = 0; i < state.N; i++) {
      float cosx = state.in[i * 4 + 0];
      float sinx = state.in[i * 4 + 1];
      float cosy = state.in[i * 4 + 2];
      float siny = state.in[i * 4 + 3];
      state.out[i * 2 + 0] = cosx * sint + sinx * cost;
      state.out[i * 2 + 1] = cosy * sint + siny * cost;
   }
}

Results:

1  
2  
Test.scalarRivenMath 2972,617 us/op
Test.sumOfAngles     2227,220 us/op

Running on a 3.1GHz Sandy Bridge i5 with Java 8u60 x64.
29  Game Development / Shared Code / Re: Extremely Fast sine/cosine on: 2015-10-07 11:34:10
EDIT: sumOfAngles wasn't computing the full data set  Emo

What was the problem exactly? I cleaned your code a bit and verified output equivalence of the 3 implementations and got:

1  
2  
3  
scalarFastMath    3110,062 us/op
scalarJavaMath  101201,482 us/op
sumOfAngles       2280,336 us/op


30  Game Development / Newbie & Debugging Questions / Re: Are people overreacting in the negative performance of GC? on: 2015-10-05 14:35:41
On escape analysis:  I'd really like to know what the current set of limitation are.  They were rather strict the last time I looked.  Likewise for scalar replacement...which boiled down to it could only happen if the call to "new" is a a function is is a leaf from the allocations perspective:  i.e. it could not be passed to any method...any method's which it was logically passed to must have been inlined.

I encountered this problem in LWJGL recently and it's still exactly like what you describe. The usual failure case looks like:

- User code allocates an object and passes it to a method
- which calls a simple method
- which calls a simple method
- ...
- which calls a complex method that uses the allocated object

Assuming that all these methods are pure and do not leak the reference anywhere else, the allocation will still occur if the final method is too big to be inlined. If the final method is in library code, one thing you could do without affecting user-code is:

1  
2  
3  
4  
5  
6  
7  
8  
9  
10  
11  
12  
13  
// before
public static void complexMethod(..., MyClass object) {
    // lots of bytecode...
}

// after
public static void complexMethod(..., MyClass object) {
    complexMethodImpl(..., object.fieldA, object.fieldB, ...);
}

private static void complexMethodImpl(..., MyClassFieldA fieldA, MyClassFieldB fieldB, ...) {
    // lots of bytecode...
}

This lets complexMethod get inlined and escape analysis will eliminate the MyClass object allocation.

As an example, the case I'm currently optimizing in LWJGL is
GL20.glShaderSource(int shader, CharSequence... strings)
and "complexMethod" is UTF-8 encoding the input strings. With the above trick, allocation of the intermediate ByteBuffers is eliminated.

(not that you'd ever call glShaderSource so many times that it'd be a problem, but the same solution can be applied to similar scenarios)
Pages: [1] 2 3 ... 32
 
KaiHH (94 views)
2016-01-31 23:15:29

sci4me (120 views)
2016-01-23 21:47:05

sci4me (107 views)
2016-01-23 21:46:58

KaiHH (140 views)
2016-01-19 13:26:42

theagentd (227 views)
2016-01-05 17:10:00

ClaasJG (241 views)
2016-01-03 16:58:36

chrisdalke (230 views)
2015-12-28 06:31:21

Guerra2442 (247 views)
2015-12-25 03:42:55

Guerra2442 (251 views)
2015-12-25 03:27:21

theagentd (287 views)
2015-12-21 14:43:24
List of Learning Resources
by SilverTiger
2016-02-05 09:39:47

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

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

Rendering resources
by Roquen
2015-11-13 14:37:59

Rendering resources
by Roquen
2015-11-13 14:36:58

Math: Resources
by Roquen
2015-10-22 07:46:10

Networking Resources
by Roquen
2015-10-16 07:12:30

Rendering resources
by Roquen
2015-10-15 07:40:48
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!