Java-Gaming.org Hi !
Featured games (84)
games approved by the League of Dukes
Games in Showcase (595)
Games in Android Showcase (168)
games submitted by our members
Games in WIP (647)
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 ... 28
1  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.
2  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.
3  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.
4  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.
5  Java Game APIs & Engines / OpenGL Development / Re: LWJGL stb bindings on: 2015-07-01 08:13:21
Thanks, fixed.
6  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.
7  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.
8  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).
9  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.
10  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.
11  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.
12  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.
13  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.
14  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.
15  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-05-27 22:56:56
I did this a few weeks ago, but it's relevant: I added ODBC bindings to a LWJGL 3 fork. Worst-case latency dropped by 10x compared to JDBC (highly optimized app on both ends, with minimal network overhead, so ymmv), there is no unnecessary garbage (query results stored off-heap) and you get actual async queries without spawning extra threads.

JDBC is yet another simplistic Java API that's good at burning CPU cycles and wasting memory bandwidth for no good reason.

Especially the MySQL JDBC library is critically bugged and so far off the spec it's funny.

I hate that LWJGL needs to exist, that the JVM does not have a native FFI. Writing bindings is painful and takes a lot of precious time, all for doing... nothing really. But I was motivated after decompiling the JDBC driver we use and seeing the horrors that laid inside. Bad API and bad implementations and everyone's using this shit.
16  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Fast, reliabe & crossplatform Javascript API/Library for Java? (for game dev.) on: 2015-05-27 18:52:04
Stay away from Rhino, go with JDK 8 and Nashorn. It's massively faster, is 100% ECMAScript 5.1 compatible and has additional features that make Java interop easier. Also make sure to keep your JDK updated; Nashorn is under active development, there have been many fixes and performance improvements and more are coming.

LWJGL works just fine with JDK 8.
17  Java Game APIs & Engines / OpenGL Development / LWJGL stb bindings on: 2015-05-21 20:32:42
The latest LWJGL 3 nightly build (#49) now features bindings to the stb collection of "single-file public domain libraries for C/C++". Not everything is supported, only libraries that make sense in Java and are lightweight enough for LWJGL.

The main motivation for adding these bindings was to allow LWJGL users to get rid of any dependencies to AWT (e.g. for loading fonts or images). There are many other options of course, but stb is a solution that was very easy to support and should cover most needs. It is developed by Sean Barrett (works at RAD Game Tools), written in pure C, with functionality focused on game development.

LWJGL includes the following bindings (under the org.lwjgl.stb package):

STBEasyFont (demo)

A quick-and-dirty solution for getting some text rendered in the simplest possible way. It provides a function that converts an ASCII string to an array of GL_QUADS, which you can then render any way you like. It's essentially a monospaced bitmap font.

It's obviously very inefficient, but you can cache the generated geometry.

STBTruetype (simple demo - advanced demo)

Parses .ttf files, returns font/glyph metrics and rasterizes fonts to packed textures.

The API is simple, but this is an advanced library; line metrics, glyph metrics, kerning, pixel snapping, oversampling for small test sizes, subpixel positioning, everything you need is here. Make sure to read this guide on oversampling. The "advanced demo" above is an LWJGL port of the "oversample" test in the stb repository.

STBRectPack

Can be used to pack rectangular textures into an atlas. It implements the Skyline Bottom-Left algorithm and is used internally by STBTruetype for the glyph packing.

STBImage (demo)

An image loading library. Supports the following image file formats:

  • JPEG baseline & progressive (12 bpc/arithmetic not supported, same as stock IJG lib)
  • PNG 1/2/4/8-bit-per-channel (16 bpc not supported)
  • TGA (not sure what subset, if a subset)
  • BMP non-1bpp, non-RLE
  • PSD (composited view only, no extra channels)
  • GIF (*comp always reports as 4-channel)
  • HDR (radiance rgbE format)
  • PIC (Softimage PIC)
  • PNM (PPM and PGM binary only)

STBImageResize

High-quality image resizing. It's sRGB-aware, alpha-aware, supports different edge wrap modes and a variety of filters (including cubic and Mitchell-Netrevalli).

If you're using glGenerateMipmap or aren't doing gamma correct mipmap generation, you really really want to use this.

STBImageWrite

Simple library for writing image files. Supports:

  • PNG
  • BMP
  • TGA
  • HDR

It is meant for saving screenshots to disk, so it is optimized for encoding speed, not compression ratio.

STBDXT

A real-time DXT1/DXT5 compressor. If you need to compress textures at runtime, this should provide better quality than the compression done by OpenGL drivers.

STBVorbis (demo)

An Ogg Vorbis audio decoder. Seeking is not properly implemented yet, only "rewind" works.

STBPerlin

Computes Perlin's revised noise function (3D input, 1D output). I'm not sure how this performs in terms of speed and quality; if anyone tests it, please post here.

General notes

Try to avoid the "filename" APIs (in STBImage, STBImageWrite and STBVorbis), they do not support unicode paths atm (on Windows). Better use standard Java IO to load the files in memory and use the corresponding APIs.

I haven't had the time to test everything, let me know if you encounter any issues. You can see a video of some of the above here (GIF, 7.43 MB).
18  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-05-21 11:57:33
It's a small C library with no dependencies, so built-in and available on all platforms.
19  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-05-21 11:39:29
The voxel library is great, but there's no API to configure it; just a bunch of compile-time #defines. So you can't really make bindings to it and keep everyone happy.

Also, I believe such high-level functionality is outside the scope of LWJGL.
20  Discussions / Miscellaneous Topics / Re: What I did today on: 2015-05-21 11:12:15
Added stb bindings to LWJGL 3:

Click to Play


(will post details when the build is up)
21  Game Development / Networking & Multiplayer / Re: How to properly benchmark server performance. on: 2015-05-17 16:09:59
Make sure your benchmark code (or any third-party software you use to measure latencies) does not suffer from Coordinated Omission. It's very easy to miss and many tools (even commercial) suffer from this problem. For solutions, see LatencyUtils and anything Gil Tene has to say on the matter.
22  Game Development / Performance Tuning / Re: Performance Slowdown (LWJGL, OSX) on: 2015-05-10 20:32:39
The code that calls [NSOpenGLContext update] was written in 2004 and seems to be related to AWT integration. It indeed seems wasteful to call on each Display.update(). If anyone feels comfortable enough to fix the code, please submit a pull request.

LWJGL 3 does not call [NSOpenGLContext update]. GLFW does not call it either, it uses NSOpenGLView, which handles geometry/display updates automatically.
23  Java Game APIs & Engines / OpenGL Development / LWJGL 3.0.0a on: 2015-04-27 19:55:18
LWJGL 3.0.0a has been released!

Read the blog post for details.
Visit the download page to get it. (direct link)
24  Game Development / Networking & Multiplayer / Orbit Framework on: 2015-04-01 10:27:02
Bioware has released its open source framework Orbit. It "makes it easier to build and maintain distributed, secure and scalable online services" and looks like an implementation of Microsoft's Orleans in Java.
25  Discussions / General Discussions / Re: Concurrency Library on: 2015-03-31 11:33:16
TL;DR: Verdict: would not use for games.

The Disruptor has not been designed to distribute tasks to a thread pool (i.e. what ForkJoinPool does with work-stealing). That is a multi-producer-multi-consumer (MPMC) problem that's going to suffer from contention and/or other overheads (e.g. garbage), no matter what you use. Just look at your single-threaded example, it's 4 times faster than the best alternative, in which case the question is, why are you even trying to use concurrency?

In order to get the most out of the Disruptor, you need to have dedicated threads doing work in stages (see SEDA). This includes many SPMC and MPSC scenarios and is perfect for controlling access (back pressure + batching) to contended resources (typically IO). ArrayBlockingQueue is a general-purpose bounded queue optimized for the worst-case (MPMC). The Disruptor, when properly configured for a specific workload (SPMC or MPSC or even SPSC), destroys ABQ in both throughput and latency. You could use it for MPMC too, but you're going to see much bigger gains with a different design, not a different queue.

The Disruptor uses a lot of tricks to reduce latency (PoT buffer size, preallocated payloads, padding objects to avoid cache-line false-sharing, etc) but I'd say its best feature is batching. Queues in a running system are usually either mostly empty (slow producer) or mostly full (slow consumer). Besides the fact that JDK queues have trouble with tail/head false-sharing, the Disruptor enables batch production or consumption of messages, which means you pay the sync overhead once per batch, instead of once per message. This does wonders for latency and CPU utilization.

Disrupter is cool, but if you're game needs it: you need to rethink your threads and how the communicate.

I think specialized solutions like the Disruptor will become very useful with the Vulkan/Mantle/D3D12-style of graphics/compute programming.
26  Discussions / General Discussions / Re: The Khronos Group announces "Vulkan": the successor to OpenGL on: 2015-03-12 10:09:03
Interesting inside info on how complicated and inefficient current DX/GL drivers are.
27  Discussions / General Discussions / Re: The Khronos Group announces "Vulkan": the successor to OpenGL on: 2015-03-11 18:37:28
In perfect world, command buffer would be fully prepared on java side in some kind of native memory buffer and then converted into real Vulcan command buffer with just a single JNI call.
Does anybody know if command buffer internal implementation will be accessible, so it can be composed directly, without using vk calls for each command?

Yes, "draw calls" in Vulkan will be data inside a command buffer, not actual function calls. There is no public information yet on how the application actually builds the command buffer. It could either be writing the data itself in a plain memory buffer, or calling functions that do it for you. From previews I've seen DX12 does the latter, but my guess is Vulkan will do the former. In either case, you'll be able to build and submit command buffers from multiple threads, which is perfect for what Java does best (concurrency) and you'll never have to worry about JNI overhead again.

It's also quite possible that by the time there's enough market share to deploy a Vulkan application, Java will have built-in FFI support, which means close-to-zero native call overhead.
28  Discussions / General Discussions / Re: The Khronos Group announces "Vulkan": the successor to OpenGL on: 2015-03-07 09:10:53
Yes, of course, it's just that writing a memory allocator is anything but trivial and we have no solution out of the box. A Java implementation (using NIO/unsafe) would also have to go through JNI a few times on each allocation. One or more native (and production-quality) implementations bundled with LWJGL would be better, but the question is which ones?
29  Discussions / General Discussions / Re: The Khronos Group announces "Vulkan": the successor to OpenGL on: 2015-03-07 08:48:36
Can we expect to see Vulkan incorporated into LWJGL?

Yes, as soon as there's a spec.

Interesting fact from the API preview: the very first thing Vulkan asks for is a user-provided memory allocator...
30  Discussions / General Discussions / Re: The Khronos Group announces "Vulkan": the successor to OpenGL on: 2015-03-05 12:31:04
Repo doesn't appear to up yet so I haven't had the chance to see if there are any strings attached.

You need to register to gain access.
Pages: [1] 2 3 ... 28
 
deepthought (49 views)
2015-06-30 15:39:44

deepthought (56 views)
2015-06-30 15:39:09

deepthought (65 views)
2015-06-30 15:36:52

Za\'Anzabar (43 views)
2015-06-29 05:44:54

TritonDreyja (49 views)
2015-06-24 17:10:40

CopyableCougar4 (52 views)
2015-06-23 00:34:45

BurntPizza (58 views)
2015-06-21 20:36:46

cookiecompiler (98 views)
2015-06-11 15:42:53

cookiecompiler (58 views)
2015-06-11 15:41:14

NegativeZero (82 views)
2015-06-11 09:49:18
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

Resources for WIP games
by kpars
2014-12-18 10:26:14
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!