Hi !
Featured games (83)
games approved by the League of Dukes
Games in Showcase (581)
Games in Android Showcase (162)
games submitted by our members
Games in WIP (632)
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  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.


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)


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.


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.


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.


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).
2  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.
3  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.
4  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)
5  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.
6  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.
7  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)
8  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.
9  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.
10  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.
11  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.
12  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?
13  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...
14  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.
15  Java Game APIs & Engines / Engines, Libraries and Tools / Re: Java OpenGL Math Library (JOML) on: 2015-02-20 11:17:26
Relevant post on angles.
16  Discussions / General Discussions / Re: What's your day job? on: 2015-02-16 14:56:12
I'm a co-owner at WebHotelier, we launched in 2008 and I've been working there ever since. Well, from home actually, the company HQ is 800km from where I live. It's nothing exciting technology-wise, even though it's a JVM based platform, I have most fun doing SQL magic (yes, there is such a thing). For the past year or so I've also been doing extensive research on a "next-gen" re-architecture of the whole thing, which should be keep things interesting. We'll need it too, since we're currently expanding internationally.

In my free time, I work on LWJGL and (try to) raise a little girl.
17  Game Development / Newbie & Debugging Questions / Re: Byte buffer crashing on: 2015-02-11 16:24:48
The latest nightly build (#39) now returns null instead of a ByteBuffer pointing at 0L.

oh, that's new in 3.x ?

correct me but with 2.9.x ngl methods are not really available and even if, native methods already return a bytebuffer .. right ? or am i blind again ?

All the 'n' methods are publicly available in LWJGL 3. At the native side these are direct calls to the native function, there's no magic happening, only casts from JNI types to native types. In theory, you could write your own high-level API on top of those and ignore anything LWJGL does at the Java side. Pointer values are mapped to long primitive values obviously. LWJGL creates ByteBuffer instances in Java, using Unsafe instead of JNI's NewDirectByteBuffer.
18  Game Development / Newbie & Debugging Questions / Re: Byte buffer crashing on: 2015-02-11 12:29:27
What's with drivers that do not expose that debug output extension?

Are there such drivers? Note, this is for development only, the deployed application does not have to require a debug output extension.

Because of this asynchronicity is it then not possible for your program to crash because of a faulty GL call before being able to receive a GL error asynchornously by the driver in time?

If that indeed happens, you can enable GL_DEBUG_OUTPUT_SYNCHRONOUS.
19  Game Development / Newbie & Debugging Questions / Re: Byte buffer crashing on: 2015-02-11 12:17:38
I'm open to returning null, but not because glGetError is "expensive". If the default behavior confuses users or makes debugging harder, then it obviously has to change.

Btw, I never said use glGetError, or fill your code with error checks. There is a reason LWJGL 3 does not have a "debug jar" like LWJGL 2, manual checking is obsolete now that we have the *_debug_output extensions and OpenGL 4.3+. Note that the error checking itself is not (more) expensive, the driver has to do it in any case, it's reporting the error that causes performance problems. This issue goes away with debug output, because the debug callbacks may be called asynchronously (i.e. not in the same thread that called the OpenGL function and triggered an error) and you also have full control of the level of error/issue reporting.
20  Game Development / Newbie & Debugging Questions / Re: Byte buffer crashing on: 2015-02-11 11:33:40
LWJGL 3 indeed by default returns a ByteBuffer pointing at 0L. If you enable debug mode (-Dorg.lwjgl.util.Debug=true) you will get an exception instead.

You could argue that it's a problem with LWJGL, but this is an application bug really. You're using the result of MapBuffer without checking for OpenGL errors. Which I'm sure what is happening here, otherwise you wouldn't be getting a null pointer back.

I highly recommend setting up a debug message callback while developing your application. It's particularly easy in LWJGL 3:

debugProc = GLContext.createFromCurrent().setupDebugMessageCallback();

Don't forget to store the returned Closure somewhere, like GLFW callbacks. You may also have to create a debug context (see the GLFW_OPENGL_DEBUG_CONTEXT window hint).
21  Java Game APIs & Engines / Engines, Libraries and Tools / Re: GLFW 3.1 is out on: 2015-01-20 15:25:14
I expected that it would bring the icon changing feature, but it didn't.. Hoping that in a future release.

Setting window icons is scheduled for GLFW 3.2.

I'm currently quite busy and lost precious time with the 2.9.3 release, but I'll try to have 3.0a ready this weekend.

I know LWJGL include an hybrid version but i hope it will include this one soon !! I found GLFW a great library.

The LWJGL nightly builds contain all GLFW 3.1 features. Only some of the latest fixes are missing.
22  Java Game APIs & Engines / OpenGL Development / LWJGL 2.9.3 on: 2015-01-19 00:49:17
LWJGL 2.9.3 has just been released, with a few bug fixes that didn't make it to LWJGL 2.9.2. Details here.

It includes an important fix for cursor movement behavior on Windows, when the mouse is grabbed. Whenever a keyboard key was held down (and repeat events fired), the cursor would stutter/drift horribly. This behavior was mostly noticeable with high repeat rates, with vsync enabled and/or with low frame rates. It also significantly affected Minecraft users (very noticeable in a 1st person view). With 2.9.3 cursor movement is now perfectly smooth.
23  Java Game APIs & Engines / OpenGL Development / Re: [SOLVED]Lwjgl Error: Failed to load the native library: lwjgl on: 2015-01-09 15:53:53
I'm pretty sure that if it determined the arch. from the JVM, and someone used a x86 JVM on x64 system, it shouldn't work, because it uses wrong natives on the machine.

A x86 JVM on a x64 machine requires x86 binaries.
24  Java Game APIs & Engines / OpenGL Development / Re: [SOLVED]Lwjgl Error: Failed to load the native library: lwjgl on: 2015-01-09 09:42:30
Which architecture can be resolved automatically? Do you talk only about the "bitness"?

Whether to use x86 or x64 binaries.
25  Java Game APIs & Engines / OpenGL Development / Re: [SOLVED]Lwjgl Error: Failed to load the native library: lwjgl on: 2015-01-09 08:20:07
Also, as of LWJGL 3, you need to specify a folder by 32bit vs 64bit.

That was a temporary limitation, you now only have to specify the base folder. The OS and CPU architecture are resolved automatically.
26  Game Development / Newbie & Debugging Questions / Re: Is LWJGL 3 stable enough for use? on: 2015-01-06 21:26:23
Incidentally, has there been any movement on that front since your lwjgl/jfx integration demo? Or are you going to wait and see what happens with the interop feature request?

I think that request will be very low priority for the JavaFX team. Also, it's only about embedding OpenGL into JavaFX; though technically possible, it will be limited to non-gaming applications imho. The other way around, rendering JavaFX content inside a native window, is much more interesting (to me at least) and should be easier to implement.

I haven't had any more time to work on the LWJGL integration demo. But I'm hoping that there's somehow a way to get inside the JavaFX runtime, such that GPU-to-GPU copies are made possible. It will probably end up being very hacky and platform-specific, but if we could build a decent demo, the JavaFX engineers might get interested.
27  Game Development / Newbie & Debugging Questions / Re: Is LWJGL 3 stable enough for use? on: 2015-01-06 13:38:14
i did not catch the full info on the LWJGLX features but afaik swing is not planned, right ?

Correct, it is not planned for 3.0. If there's enough free time after 3.0, I'm still interested in exploring interop solutions, especially for JavaFX. Obviously, I'll be glad to help if you need assistance.

Note that LWJGL 3 exposes all platform-specific context management functions and you can even call anything missing using libFFI. There will also soon be bindings to the Objective C Runtime (for interacting with Cocoa).
28  Game Development / Newbie & Debugging Questions / Re: Is LWJGL 3 stable enough for use? on: 2015-01-06 12:47:40
You can think of LWJGL 2 as two parts; the bindings to native libraries and the cross-platform window/context/input/controller API.

The bindings in LWJGL 2 are a very thin layer on top of the native libraries they expose. The bindings in LWJGL 3 are just as thin (thinner actually) and are very compatible with LWJGL 2. They are not 100% compatible because of some bug fixes here and there and the OpenCL bindings redesign. They are much nicer though; you get unsafe bindings (direct access to the JNI functions), more convenient overloads and, best of all, inline documentation.

The rest of LWJGL 2 is (relatively) a lot of code, written in both Java and C/ObjC. It is what it is, does the job for which is was designed well, but has the known problems and limitations. LWJGL 3 on the other hand, does not have anything like that. There are some classes, like the GLContext and the ContextCapabilities, but that's it. There is nothing there to be stable or not. Everything related to windows, monitors, contexts, keyboard, mouse and controllers is being done with GLFW. Which is yet another library binding in LWJGL 3. So, the real question is if GLFW is mature enough. Well, it's a library almost as old as the original LWJGL, but has been rewritten in version 3.0, just like LWJGL. We're currently close to the 3.1 release and I'll quote its developer:

GLFW 3.1 has closed more issues than every previous release combined since GLFW moved to its current home on GitHub. Two issues remaining.

Other than, I'll just say you're going to have to try it and judge for yourselves. Disclaimer: GLFW does everything (much) better than LWJGL 2. There is only one feature missing and that's setting window icons programmatically. It will be added in GLFW 3.2.

With that said, I'll repeat here that LWJGL 3.0 has not been released yet. There's not even an official "alpha" build available. There are many users trying the nightly builds though and many platform/environment-specific issues have been resolved. I'm pretty confident that the first official release (scheduled for when GLFW 3.1 is out) will be stable enough for everyone to enjoy. Of course, it would be irresponsible to say right now that you should start porting your applications to LWJGL 3. The bindings are incomplete (e.g. many OpenGL extensions and OpenGL ES are missing, OpenAL needs work) and we'd like to be open to feedback for the rest of the API right until the final 3.0 release (the API will freeze then). The non-binding API is so small though, that any breaking changes will have minimal impact to early-adopters.

My unofficial/personal/humble opinion is: If you don't need AWT/applet interop, there is no reason whatsoever to stick with LWJGL 2. Smiley
29  Discussions / General Discussions / Re: System requirements for Oculus Rift? on: 2015-01-05 12:12:11
I'd like to add that LWJGL 3 will soon have libOVR bindings (currently WiP). Also, here's an unfinished guide on how to use GLFW with libOVR to detect an Oculus Rift.
30  Game Development / Newbie & Debugging Questions / Re: GLFW input handling not smooth on: 2014-12-31 23:25:55
Try changing:

mouseDown = (action == GLFW.GLFW_PRESS);


mouseDown = (action != GLFW.GLFW_RELEASE); // either PRESS or REPEAT
Pages: [1] 2 3 ... 28
MrMapcom (13 views)
2015-05-23 20:26:16

MrMapcom (19 views)
2015-05-23 20:23:34

Waterwolf (29 views)
2015-05-20 15:01:45

chrislo27 (35 views)
2015-05-20 03:42:21

BurntPizza (70 views)
2015-05-10 15:53:18

FrozenShade (56 views)
2015-05-07 09:11:21

TheLopais (218 views)
2015-05-06 13:36:48

TheLopais (202 views)
2015-05-06 13:35:14

TheLopais (207 views)
2015-05-06 13:33:39

TheLopais (226 views)
2015-05-06 13:32:48
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

Understanding relations between setOrigin, setScale and setPosition in libGdx
by mbabuskov
2014-10-09 22:35:00

Definite guide to supporting multiple device resolutions on Android (2014)
by mbabuskov
2014-10-02 22:36:02

List of Learning Resources
by Longor1996
2014-08-16 10:40:00 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‑
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!