LWJGL is a Java library that enables cross-platform access to popular native APIs useful in the development of graphics (OpenGL, Vulkan), audio (OpenAL), parallel computing (OpenCL, CUDA) and XR (OpenVR, LibOVR) applications.

Overview

Maven Central API Javadoc License

Backers on Open Collective Sponsors on Open Collective Size Build Status

LWJGL - Lightweight Java Game Library 3

LWJGL (https://www.lwjgl.org) is a Java library that enables cross-platform access to popular native APIs useful in the development of graphics (OpenGL/Vulkan), audio (OpenAL) and parallel computing (OpenCL) applications. This access is direct and high-performance, yet also wrapped in a type-safe and user-friendly layer, appropriate for the Java ecosystem.

LWJGL is an enabling technology and provides low-level access. It is not a framework and does not provide higher-level utilities than what the native libraries expose. As such, novice programmers are encouraged to try one of the frameworks or game engines that make use of LWJGL, before working directly with the library.

LWJGL is open source software and freely available at no charge.

Useful links:

Contact:

If you'd like to contribute, see doc/README for a quick overview of the project structure, installation instructions and configuration options.

Getting Started

As of version 3.1.0, LWJGL is distributed as a set of modules. Only the core module is required and all bindings are optional (but some bindings depend on other bindings). The easiest way to download LWJGL is to use the build configurator on the website.

The build configurator generates Maven & Gradle declarations that can be added to existing projects. This is the easiest way to use LWJGL while developing.

LWJGL can also be downloaded as a simple set of JAR files. Each module consists of the following files:

  • lwjgl-<module>.jar
  • lwjgl-<module>-sources.jar
  • lwjgl-<module>-javadoc.jar
  • lwjgl-<module>-natives-<platform>.jar (for some bindings)

To compile and run an LWJGL application, the base and natives JAR files of the core module and each binding used should be added to the classpath. LWJGL extracts the natives to a temporary folder and loads them automatically, so no further configuration is necessary. If more customization is required (e.g. when creating a platform-specific installer) the natives may be extracted manually and loaded via java.library.path. See the Configuration class for more options.

LWJGL 3 requires Java 8 or later to build and run and currently supports the following platforms/architectures:

  • Linux x64
  • Linux arm64 (ARMv8/AArch64)
  • Linux arm32 (ARMv7/armhf)
  • macOS x64
  • Windows x64
  • Windows x86

Example code:

For migrating LWJGL 2 code to LWJGL 3, see the Migration Guide.

Troubleshooting

Most common issues faced by LWJGL users are trivially addressed with the following:

LWJGLX/debug is a Java Agent that will automatically detect a lot of these issues. It can also generate a trace log that's useful when reporting issues to LWJGL.

When asking for help or when you suspect a bug in LWJGL, preparing an MVCE (Minimal, Complete, and Verifiable example) that reproduces the issue will improve the chances of a quick and useful response.

List of Supported Bindings

Khronos APIs

Library Description
EGL An interface between Khronos rendering APIs such as OpenGL ES or OpenVG and the underlying native platform window system.
OpenCL An open, royalty-free standard for cross-platform, parallel programming of diverse processors found in personal computers, servers, mobile devices and embedded platforms.
OpenGL The most widely adopted 2D and 3D graphics API in the industry, bringing thousands of applications to a wide variety of computer platforms.
OpenGL ES A royalty-free, cross-platform API for full-function 2D and 3D graphics on embedded systems - including consoles, phones, appliances and vehicles.
Vulkan A new generation graphics and compute API that provides high-efficiency, cross-platform access to modern GPUs used in a wide variety of devices from PCs and consoles to mobile phones and embedded platforms.

Display and Input

Library Description
GLFW Create multiple windows, handle user input (keyboard, mouse, gaming peripherals) and manage contexts. Also features multi-monitor support, clipboard access, file drag-n-drop, and much more.
JAWT The AWT native interface.
nfd A tiny, neat C library that portably invokes native file open and save dialogs.
tinyfd A native dialog library.

Audio

Library Description
OpenAL A cross-platform 3D audio API appropriate for use with gaming applications and many other types of audio applications.
OpenAL Soft An LGPL-licensed, cross-platform, software implementation of the OpenAL 3D audio API.
Opus A totally open, royalty-free, highly versatile audio codec.

Graphics

Library Description
Assimp A portable Open Source library to import various well-known 3D model formats in a uniform manner.
bgfx Cross-platform, graphics API agnostic, “Bring Your Own Engine/Framework” style rendering library, licensed under permissive BSD-2 clause open source license.
DriftFX A library that allows you to render any OpenGL content directly into JavaFX nodes.
LibOVR The API of the Oculus SDK.
meshoptimizer A mesh optimization library that makes meshes smaller and faster to render.
NanoSVG A simple stupid SVG parser.
NanoVG A small antialiased vector graphics rendering library for OpenGL.
Nuklear A minimal state immediate mode graphical user interface toolkit written in ANSI C and licensed under public domain.
par_shapes Generate parametric surfaces and other simple shapes.
par_streamlines Triangulate wide lines and curves.
OpenVR An API and runtime that allows access to VR hardware from multiple vendors without requiring that applications have specific knowledge of the hardware they are targeting.
Shaderc A collection of libraries for shader compilation.
SPIRV-Cross A library for performing reflection on SPIR-V and disassembling SPIR-V back to high level languages.
Tiny OpenEXR A small, single header-only library to load and save OpenEXR(.exr) images.
Tootle (AMD) A 3D triangle mesh optimization library that improves on existing mesh preprocessing techniques.
Vulkan Memory Allocator An easy to integrate Vulkan memory allocation library.
Yoga An open-source, cross-platform layout library that implements Flexbox.

stb - single-file public domain libraries for C/C++

Library Description
stb_easy_font Quick-and-dirty easy-to-deploy bitmap font for printing frame rate, etc.
stb_image Image loading/decoding from file/memory: JPG, PNG, TGA, BMP, PSD, GIF, HDR, PIC
stb_image_resize Resize images larger/smaller with good quality.
stb_image_write Image writing to disk: PNG, TGA, BMP
stb_perlin Revised Perlin noise (3D input, 1D output).
stb_rect_pack Simple 2D rectangle packer with decent quality.
stb_truetype Parse, decode, and rasterize characters from truetype fonts.
stb_vorbis Decode ogg vorbis files from file/memory to float/16-bit signed output.

Other

Library Description
Bullet Physics Real-time collision detection and multi-physics simulation for VR, games, visual effects, robotics, machine learning etc.
CUDA A parallel computing platform and programming model developed by NVIDIA for general computing on GPUs.
jemalloc A general purpose malloc implementation that emphasizes fragmentation avoidance and scalable concurrency support.
libffi A portable, high level programming interface to various calling conventions.
libdivide A library that replaces expensive integer divides with comparatively cheap multiplication and bitshifts.
LLVM A collection of modular and reusable compiler and toolchain technologies.
LMDB An extraordinarily fast, memory-efficient database. With memory-mapped files, it has the read performance of a pure in-memory database while retaining the persistence of standard disk-based databases.
LZ4 A lossless data compression algorithm that is focused on compression and decompression speed.
Meow hash An extremely fast non-cryptographic hash.
ODBC A C programming language interface that makes it possible for applications to access data from a variety of database management systems (DBMSs).
Remotery A realtime CPU/GPU profiler hosted in a single C file with a viewer that runs in a web browser.
rpmalloc A public domain cross platform lock free thread caching 16-byte aligned memory allocator implemented in C.
xxHash An Extremely fast Hash algorithm, running at RAM speed limits.
Zstandard (zstd) A fast lossless compression algorithm, targeting real-time compression scenarios at zlib-level and better compression ratios.

Use of a binding is subject to the terms of the corresponding license.

Supporting this project

LWJGL exists thanks to all the people who contribute and back/sponsor our collective.

Our gold sponsors:

Comments
  • Bullet C API first thoughts

    Bullet C API first thoughts

    Hi! This is more of an opinion but now that I've been trying to port my stuff to Bullet's C API and worked a bit with it I'm having doubts about it.

    The API itself is very awkward to use. I didn't think it'd be a problem but all the indirect handles and indices you have to keep around to operate on things are very annoying.

    The API refuses to work with structs directly, since it's thought as a client-server architecture, what you have on the "client side" are usually int64 handles or int32 indices referring to some item on the server side, and a set of many functions that each mutate/read a field of the logical structure on the server side, one by one.

    The API is robotics and Python oriented, so I am guessing it only exposes what is useful and practical for both of them.

    This means that something really useful in games like collision filters isn't there by default, you have to enable it through a plugin. Moreover, something like a kinematic body (like say, a player) isn't there at all, so instead of setting the velocity of the player you have to move it around with instantaneous forces (unless there is actually a way and I'm an idiot), using forces this way is very hard to fine tune player movement or anything really.

    This also means there is a lot of fluff there that isn't relevant for games at all. There are a lot of core functions there purely dedicated to work with the included visualizer of the physics simulation. Until very recently the only way to load an arbitrary mesh body was through a robotics focused file format, instead of you know, an array of vertices.

    What I am trying to say is that the client-server layer between the user and Bullet isn't helping at all. It's just bloat a game doesn't needs.

    Now the thing is that for 3D there aren't many physics libraries to use out there. And out of them all, Bullet is probably the most documented and widely used, although that's the case for the plain C++ library, not the C API, I doubt there is any game made with it.

    It doesn't means there aren't any alternatives:

    Newton Dynamics has a C API, seems pretty clean and it has been used on a few relevant games(Mount & Blade, Frictional Games stuff, ie SOMA and Amnesia). Even less examples although it has a demo project with a bunch of things. It's zlib licenced.

    Open Dynamics Engine has been used on a bunch of games (Techland stuff, ie Call of Juarez, Dead Island) and I've read it has a C API... I just don't understand enough of the repo to know where to look for it. Looking for examples I get results from 2006. It's BSD or LGPL licenced. There is a Java port of it but it uses 64 bit floats everywhere and the first issue you see in the repo is an unresolved high garbage creation complaint from 2015, both of them bad signs.

    I think I like more Newton Dynamics since it looks more like what you'd expect of a "proper" C library. Like a single header with most of the structs and function definitions for starters. I don't really know how hard it'd be to have bindings for it too so people (like me!) can try it out.

    In any case, for now I'll keep trying to work with Bullet's C API and probably nag the author about some missing functionality as/if I find it, since as I've said in another occasion, with it I can get rid of libGDX as a dependency in my project which is a big plus for me.

    Type: Maintenance Status: Abandoned 
    opened by dustContributor 67
  • OSGi native libraries take 3

    OSGi native libraries take 3

    Hello again!

    It seems that I may have spoken too soon at the end of #216: What I had was actually working by accident due to a quirk of the OS I was using at the time.

    Currently, LWJGL still can't be made to work on OSGi due to the way it looks up native libraries. I'll try to walk through what happens.

    Firstly, I'm working from the assumption that I'll be repackaging the existing LWJGL jar files such that they become OSGi bundles, and therefore native libraries relative to each bundle will be embedded into each bundle. So, for example, the libjemalloc.so library will be inserted into an lwjgl-jemalloc bundle. Because OSGi (in addition to languages like Ceylon, and systems such as JBoss modules) uses a "peer to peer" classloading model, each bundle is loaded in its own classloader. This means that code can't pick an essentially arbitrary classloader and try to load a library from that classloader as if it were a resource; the file will most likely not be accessible via that specific classloader.

    With that in mind, let's follow the execution path of Library.loadSystem("lwjgl")...

            @SuppressWarnings("try")
    	public static void loadSystem(String name) throws UnsatisfiedLinkError {
    		apiLog("Loading library (system): " + name);
    		if ( Paths.get(name).isAbsolute() ) {
    			System.load(name);
    			apiLog("\tSuccess");
    			return;
    		}
    
    

    The isAbsolute path won't be taken, because "lwjgl" isn't absolute. Therefore...

                    String libName = Platform.get().mapLibraryName(name);
    
    		URL libURL = Library.class.getResource("/" + libName);
    		if ( libURL == null ) {
    			// Try org.lwjgl.librarypath
    			if ( loadSystem(libName, Configuration.LIBRARY_PATH) )
    				return;
    		} else {
    

    The returned libName will be liblwjgl.so on this platform. Due to the peer-to-peer classloading described above, libURL will be null, so we jump to another overload of loadSystem...

    private static boolean loadSystem(String libName, Configuration<String> property) {
    	String paths = property.get();
    	return paths != null && loadSystem(libName, property.getProperty(), paths);
    }
    

    Now this is conditional based on the current configuration, but in an OSGi context, I would expect the property to be unset, therefore we return false here. As a result, we end up...

    		// Then java.library.path
    		String paths = System.getProperty(JAVA_LIBRARY_PATH);
    		if ( paths != null ) {
    			try {
    				System.loadLibrary(name);
    
    				Path libFile = findLibrary(paths, libName);
    				if ( libFile != null ) {
    					apiLog(String.format("\tLoaded from %s: %s", JAVA_LIBRARY_PATH, libFile));
    					checkHash(libFile);
    				}
    				return;
    			} catch (Throwable t) {
    				apiLog(String.format("\t%s not found in %s", libName, JAVA_LIBRARY_PATH));
    			}
    		}
    
    		printError(true);
    		throw new UnsatisfiedLinkError("Failed to locate library: " + libName);
    

    Now, again, in an OSGi context, we'd expect JAVA_LIBRARY_PATH not to be set. This means that the call to System.loadLibrary won't happen and an exception is raised. We can set JAVA_LIBRARY_PATH to some nonsense value such as /nonexistent, but this is pretty damn ugly and I've no idea if it would even work properly across platforms.

    The situation is slightly worse for libraries loaded via loadNative because although most of the above logic is the same, the method doesn't fall back to System.loadLibrary and therefore the library will be loaded from the host's filesystem, even though we've bundled a guaranteed-compatible native library for libraries such as jemalloc and glfw!

    I think I'd like to restate my position that the cleanest way to deal with all of this is to provide a property that can be enabled that simply bypasses all of the above and uses System.loadLibrary directly. I appreciate that you've had support problems with this in the past as it's not really traceable, but it's currently required to work in systems like OSGi and languages like Ceylon and is reliable in the context of those systems (because they have standardized, well-understood ways of including native code).

    Type: Bug 
    opened by io7m 41
  • Modular design for build artifacts

    Modular design for build artifacts

    LWJGL currently has several bindings, with more coming in the future. Many users will only use a subset of those, but they all come in a single, monolithic archive. We should consider updating the build process to create separate archives for each binding, that can be downloaded and deployed independently. This should be in addition to the fat archive that will still be available, for convenience.

    We may only do this for large APIs, especially those that come with their own shared libraries (currently jemalloc, GLFW, OpenAL and soon hwloc). The new design should ensure that loading the shared libraries is as easy/simple as before.

    Type: Enhancement 
    opened by Spasi 37
  • Rendering to multiple windows in a single thread crashes Application

    Rendering to multiple windows in a single thread crashes Application

    I copied "lwjgl3/modules/core/src/test/java/org/lwjgl/demo/glfw/MultipleWindows.java" and added rendering code that uses VBOs and VAOs. The first Window renders well but the seconds window render call crashes the application. I debugged the app step by step and found the crashing line. The chrashing line: GL11.glDrawElements(GL11.GL_TRIANGLES, model.getIndexCount(), GL11.GL_UNSIGNED_INT, 0);

    Is this a bug? If not, how can I fix this?

    Type: Question 
    opened by Klotzi111 31
  • Add version number to library names

    Add version number to library names

    The main library is always called lwjgl.jar, and the native library is always called lwjgl.dll (on Win64, as an example).

    The name should be extended with the version number of the library. For example, it should be called lwjgl-3.1.1.jar and lwjgl-3.1.1.dll to make it possible to disambiguate between different versions, and make sure that the JAR and the native library match.

    Type: Question 
    opened by javagl 28
  • Submodules can no longer find Native Bindings

    Submodules can no longer find Native Bindings

    Environment

    • LWJGL version: 3.3.0
    • LWJGL build #: Shapshot-9?
    • Java version: 1.8
    • IDE: Eclipse Neon (Using Gradle)
    • Platform: Windows
    • Modules: Core/GL/AL/STB/Jemalloc

    Description

    I very recently split my engine apart from game + engine in 1 project to have 2 projects. And link the engine via a "GitModule". Turns out Version 3.3.0 does not like that and can not find Natives anymore. The game starts up normal, but triggers breakpoints that LWJGL 3 couldn't find its natives and i have to manually let it skip these breakpoints to finish loading the setup.

    The code that triggers this is:

    GLFWErrorCallback.createPrint(System.err).set();
    

    Which is exactly like this: https://github.com/LWJGL/lwjgl3-demos/blob/main/src/org/lwjgl/demo/opengl/instancing/GrassDemo.java#L94

    After testing around i found out that it is only 3.3.0 that has these issues the moment i switch back to 3.2.4 everything works without issues. Also trying only the submodule or the main project with 3.3.0 causes the same behavior.

    Not sure what causes this though.

    Type: Question 
    opened by Speiger 27
  • New bindings to OpenXR

    New bindings to OpenXR

    Just as a foreword this is my first time creating a pull request this large so apologies in advance if there are any glaring issues that I missed.

    OpenXR is a new cross platform and generic XR api that can be treated as the replacement for OpenVR

    Using a tweaked version of vulkangen (which I will create a pull request for after cleaning it up) I have generated functional bindings to the OpenXR api. Currently the templates lack documentation since I wanted to get a working product ASAP. I have also created a functional demo which requires an OpenXR runtime and a stereo headset.

    Linux / MacOS support is very limited as I don't have the capacity to run either of those at the moment, but hopefully it should be as simple as adding the needed natives and a few lines of code to the sample.

    If you want to get a better grasp of the api this is a well documented demo of a working OpenXR app in c++

    Natives:

    Although the OpenXR runtime is a shared library similar to vulkan-1.dll the intended way to use the library is using the OpenXR-Loader. In the case of LWJGL it should be bundled into a jar file similar to glfw.dll. The OpenXR-Loader takes care of locating and loading the selected runtime, then provides all of the needed functions such as xrGetInstanceProcAddr. Currently the binaries have to be provided manually at bin/libs/native/windows/x64/org/lwjgl/openxr/openxr_loader.dll but I expect that they can be treated the same as the glfw binaries. That is having them compiled remotely on a server and then downloaded when needed.

    Precompiled OpenXR-Loader binaries for windows can be downloaded from here And the OpenXR-Loader source and build scripts can be found here

    Runtime:

    If you want to use the bindings then you will need to have the OpenXR runtime installed. Oculus devices should come with one preinstalled otherwise this describes how to install them with Steam VR

    Type: Enhancement 
    opened by Sorenon 26
  • Provide support for ARM64/M1 devices (Windows and macOS)

    Provide support for ARM64/M1 devices (Windows and macOS)

    Hi all,

    I work on the Microsoft Java Engineering Group, and I'd like to openly discuss how we can help port LWJGL to Windows on ARM64 devices (e.g. Surface X) as well as macOS on Apple Silicon M1.

    Best, Bruno Borges

    Type: Enhancement 
    opened by brunoborges 25
  • Java 9 got released!

    Java 9 got released!

    So, how well LWJGL 3 plays with it and jigzaw? I remember @Spasi mentioning something about moving to VarHandles instead of relying on sun.misc.Unsafe. What would this entail?

    Type: Enhancement Status: Completed 
    opened by dustContributor 24
  • X Error of failed request: RenderBadPicture (invalid Picture parameter)

    X Error of failed request: RenderBadPicture (invalid Picture parameter)

    I'm currently facing a very weird issue: In one of my projects I'm getting the following error during initialization. My initialization code is pretty much identical to the Pong example code, with added logging statements to see the steps of the initialization:

    [LWJGL] Version: 3.0.0b SNAPSHOT
    [LWJGL]      OS: Linux v3.13.0-79-generic
    [LWJGL]     JRE: 1.8.0_74 amd64
    [LWJGL]     JVM: Java HotSpot(TM) 64-Bit Server VM v25.74-b02 by Oracle Corporation
    [LWJGL] Loaded library from java.library.path: lwjgl
    [LWJGL] MemoryUtil accessor: MemoryAccessorUnsafe
    [LWJGL] Loaded native library: lib/native/libjemalloc.so
    [LWJGL] MemoryUtil allocator: JEmallocAllocator
     *** glfwInit
    [LWJGL] Loaded native library: lib/native/libglfw.so
         glfwInit [done]
     *** setting glfwSetErrorCallback
         setting glfwSetErrorCallback [done]
     *** setting glfwWindowHint
         setting glfwWindowHint [done]
     *** glfwCreateWindow
    X Error of failed request:  RenderBadPicture (invalid Picture parameter)
      Major opcode of failed request:  139 (RENDER)
      Minor opcode of failed request:  6 (RenderSetPictureClipRectangles)
      Picture id in failed request: 0x540005e
      Serial number of failed request:  3285
      Current serial number in output stream:  3287
    java.lang.RuntimeException: Nonzero exit code returned from runner: 1
        at scala.sys.package$.error(package.scala:27)
    

    The reason for the vague statement "during initialization" is that the error seems to be asynchronous, and it is not always happening in glfwCreateWindow. For instance, this is output of another run, where I somehow made it past the glfwCreateWindow:

    < ... as before ... >
     *** setting glfwSetErrorCallback
         setting glfwSetErrorCallback [done]
     *** setting glfwWindowHint
         setting glfwWindowHint [done]
     *** glfwCreateWindow
    X Error of failed request:  RenderBadPicture (invalid Picture parameter)
      Major opcode of failed request:  139 (RENDER)
      Minor opcode of failed request:  6 (RenderSetPictureClipRectangles)
      Picture id in failed request: 0x560005d
      Serial number of failed request:  3523
      Current serial number in output stream:  3525
         glfwCreateWindow [done]
     *** glfwMakeContextCurrent
    pure virtual method called
    terminate called without an active exception
    java.lang.RuntimeException: Nonzero exit code returned from runner: 134
    

    Note that the error in this case also comes with an additional pure virtual method called, which is not the case when it happens in other places.

    Another example: If I don't call glfwInit right at the start of the main function, the error always seems to be triggered by glfwInit itself, i.e., I do not get to the point of setting the error callback etc. I was actually very surprised to see that the behavior changes depending on whether I place glfwInit before or after the other initialization code, because this other code has nothing to do with OpenGL / native libraries and just initializes a few Java/Scala data structures.

    I do get this error with both the latest stable build (build #3.0.0b build 64) and the latest nightly (build #3.0.0 build 41). My system is an Ubuntu 14.04, 64bit, Java 1.8.0_74, Nvidia Geforce GTX 670, Nvidia driver version 352.79.

    What makes this issue even more annoying is the fact that it seems to be difficult to reproduce: So far, I get this error only in my main project. I was trying to come up with a minimal example to reproduce it, but in the minimal example the exact same code works. I'm currently trying to add some complexity from the big project to the minimal example to see what may trigger the problem. But even after adding all dependencies and using exactly the same JVM options, I could not reproduce the error so far. I'm now looking into other potential side effects...

    I should add: I have just ported the big project from LWJGL 2.9.1 to 3.X for the first time. With 2.9.1 everything was working fine.

    Any hints what could possibly go wrong would be highly appreciated.

    3rd party 
    opened by bluenote10 24
  • Vulkan support.

    Vulkan support.

    So Khronos has made an official announcement for Vulkan https://www.khronos.org/vulkan

    Khronos says the API will be available later this year (maybe for SIGGRAPH? Hopefully sooner). Apparently its a fairly compact API, although I'm not sure how the shader compiling process will work (part of the API? external tool? vendor provided? another library?) nor how LWJGL would fit in that.

    I, for one, welcome our new low level API overlord with a big hug :smile:

    Type: Enhancement 
    opened by dustContributor 24
  • Vulkan .pNext

    Vulkan .pNext

    Question

    Hello, on VkPhysicalDeviceProperties2 and VkPhysicalDeviceFeatures2 I recently ran into a scenario where I was using the pNext to set a pointer, but because in the code both VkPhysicalDeviceProperties2 and VkPhysicalDeviceFeatures2 overwrite the pNext of the structure being passed into them if the structure is one of the overridden types, it did not work as initially intended. After digging in the code I found where this was happening, and changed my code to pass the address of the struct to the pNext.

    Example:

    physicalDeviceRayTracingPipelineProperties = VkPhysicalDeviceRayTracingPipelinePropertiesKHR.calloc()
            .sType$Default();
    physicalDeviceAccelerationStructureProperties = VkPhysicalDeviceAccelerationStructurePropertiesKHR.calloc()
            .sType$Default()
            .pNext(physicalDeviceRayTracingPipelineProperties.address());
    physicalDeviceIDProperties = VkPhysicalDeviceIDProperties.calloc()
            .sType$Default()
            .pNext(physicalDeviceRayTracingPipelineProperties.address());
    physicalDeviceProperties2 = VkPhysicalDeviceProperties2.calloc()
            .sType$Default()
            .pNext(physicalDeviceIDProperties);
    

    In this example, only the VkPhysicalDeviceIDProperties struct is actually passes to VkPhysicalDeviceProperties2 because in VkPhysicalDeviceProperties2 the function is overloaded as:

    public VkPhysicalDeviceProperties2 pNext(VkPhysicalDeviceIDProperties value) { return this.pNext(value.pNext(this.pNext()).address()); }
    

    Which overwrites the pNext of the VkPhysicalDeviceIDProperties struct.

    IIRC the vulkan C++ API does not do this (although I could be wrong). Perhaps if this is additional functionality that is intended, the function could be renamed to pNext$Append

    Thank you, Trevor

    Type: Question 
    opened by tlf30 0
  • Build 3.3.1 on CentOS 7

    Build 3.3.1 on CentOS 7

    Question

    CentOS 7.9.2009 x86_64 with all updates installed. GLIBC 2.17.

    * Linux: Shared libraries are now built on Ubuntu 18.04 (up from Ubuntu 16.04) (B)
        - GLIBC versions older than 2.14 are no longer supported. Some, but not all, LWJGL natives may require up to GLIBC 2.27.
        - Applications deployed on older systems must now build & bundle custom LWJGL natives. Contact LWJGL developers if you need assistance.
    

    Steps got from different places - can't find instruction:

    wget https://github.com/LWJGL/lwjgl3/archive/refs/tags/3.3.1.tar.gz
    tar -zxf 3.3.1.tar.gz
    cd lwjgl3-3.3.1
    export ANT_OPTS=-Xmx2G
    export LWJGL_BUILD_TYPE=release/3.3.1
    export JAVA_HOME=/usr/lib/jvm/java-11-openjdk/bin/java
    ant compile-templates
    ant generate
    ant compile
    

    Without erros: BUILD SUCCESSFUL

    But this one fails:

    ant compile-native
    
    Buildfile: /root/lwjgl3-3.3.1/build.xml
    
    init:
     [override] Build type: release/3.3.1
    
    check-dependencies:
    
    generate:
    
    compile:
    
    compile-native:
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64
    
    compile-native-platform:
     [Compiler] gcc --version: "gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-44)"
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/core
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/lmdb
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/libdivide
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/llvm
          [gcc] Linking lwjgl_libdivide
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/libdivide
     [Compiler] In file included from ../../../../modules/lwjgl/core/src/main/c/linux/liburing/include/liburing.h:20:0,
     [Compiler]                  from /root/lwjgl3-3.3.1/modules/lwjgl/core/src/main/c/linux/liburing/syscall.h:14,
     [Compiler]                  from /root/lwjgl3-3.3.1/modules/lwjgl/core/src/main/c/linux/liburing/queue.c:5:
     [Compiler] ../../../../modules/lwjgl/core/src/main/c/linux/liburing/include/liburing/barrier.h:56:23: фатальная ошибка: stdatomic.h: Нет такого файла или каталога
     [Compiler]  #include <stdatomic.h>
     [Compiler]                        ^
     [Compiler] компиляция прервана.
          [gcc] Linking lwjgl_llvm
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/llvm
     [Compiler] In file included from ../../../../modules/lwjgl/core/src/main/c/linux/liburing/include/liburing.h:20:0,
     [Compiler]                  from /root/lwjgl3-3.3.1/modules/lwjgl/core/src/main/c/linux/liburing/syscall.h:14,
     [Compiler]                  from /root/lwjgl3-3.3.1/modules/lwjgl/core/src/main/c/linux/liburing/register.c:5:
     [Compiler] ../../../../modules/lwjgl/core/src/main/c/linux/liburing/include/liburing/barrier.h:56:23: фатальная ошибка: stdatomic.h: Нет такого файла или каталога
     [Compiler]  #include <stdatomic.h>
     [Compiler]                        ^
     [Compiler] компиляция прервана.
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/lz4
     [Compiler] In file included from ../../../../modules/lwjgl/core/src/main/c/linux/liburing/include/liburing.h:20:0,
     [Compiler]                  from /root/lwjgl3-3.3.1/modules/lwjgl/core/src/main/c/linux/liburing/syscall.h:14,
     [Compiler]                  from /root/lwjgl3-3.3.1/modules/lwjgl/core/src/main/c/linux/liburing/setup.c:5:
     [Compiler] ../../../../modules/lwjgl/core/src/main/c/linux/liburing/include/liburing/barrier.h:56:23: фатальная ошибка: stdatomic.h: Нет такого файла или каталога
     [Compiler]  #include <stdatomic.h>
     [Compiler]                        ^
     [Compiler] компиляция прервана.
     [Compiler] In file included from ../../../../modules/lwjgl/core/src/main/c/linux/liburing/include/liburing.h:20:0,
     [Compiler]                  from /root/lwjgl3-3.3.1/modules/lwjgl/core/src/main/c/linux/liburing/syscall.h:14,
     [Compiler]                  from /root/lwjgl3-3.3.1/modules/lwjgl/core/src/main/c/linux/liburing/syscall.c:22:
     [Compiler] ../../../../modules/lwjgl/core/src/main/c/linux/liburing/include/liburing/barrier.h:56:23: фатальная ошибка: stdatomic.h: Нет такого файла или каталога
     [Compiler]  #include <stdatomic.h>
     [Compiler]                        ^
     [Compiler] компиляция прервана.
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/meow
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/meshoptimizer
     [Compiler] g++: ошибка: unrecognized command line option «-std=gnu++14»
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/nanovg
          [gcc] Linking lwjgl_meow
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/meow
     [Compiler] In file included from /root/lwjgl3-3.3.1/modules/lwjgl/nanovg/src/generated/c/org_lwjgl_nanovg_Blendish.c:11:0:
     [Compiler] ../../../../modules/lwjgl/nanovg/src/main/c/blendish.h: В функции «bndJoinAreaOverlay»:
     [Compiler] ../../../../modules/lwjgl/nanovg/src/main/c/blendish.h:1894:5: ошибка: «for» loop initial declarations are only allowed in C99 mode
     [Compiler]      for (int i = 1; i < count; ++i) {
     [Compiler]      ^
     [Compiler] компиляция прервана из-за -Wfatal-errors.
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/nfd
     [Compiler] In file included from /usr/include/glib-2.0/glib/galloca.h:32:0,
     [Compiler]                  from /usr/include/glib-2.0/glib.h:30,
     [Compiler]                  from /usr/include/gtk-3.0/gdk/gdkconfig.h:13,
     [Compiler]                  from /usr/include/gtk-3.0/gdk/gdk.h:30,
     [Compiler]                  from /usr/include/gtk-3.0/gtk/gtk.h:30,
     [Compiler]                  from /root/lwjgl3-3.3.1/modules/lwjgl/nfd/src/main/c/nfd_gtk.c:10:
     [Compiler] /usr/include/glib-2.0/glib/gtypes.h:32:24: фатальная ошибка: glibconfig.h: Нет такого файла или каталога
     [Compiler]  #include <glibconfig.h>
     [Compiler]                         ^
     [Compiler] компиляция прервана.
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/nuklear
          [gcc] Linking lwjgl_lmdb
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/lmdb
          [gcc] Linking lwjgl_lz4
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/lz4
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/opengl
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/opengles
          [gcc] Linking lwjgl_nuklear
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/nuklear
     [Compiler] In file included from /root/lwjgl3-3.3.1/modules/lwjgl/nanovg/src/generated/c/org_lwjgl_nanovg_OUI.c:13:0:
     [Compiler] ../../../../modules/lwjgl/nanovg/src/main/c/oui.h: В функции «uiClear»:
     [Compiler] ../../../../modules/lwjgl/nanovg/src/main/c/oui.h:940:5: ошибка: «for» loop initial declarations are only allowed in C99 mode
     [Compiler]      for (int i = 0; i < ui_context->last_count; ++i) {
     [Compiler]      ^
     [Compiler] компиляция прервана из-за -Wfatal-errors.
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/openvr
          [gcc] Linking lwjgl_openvr
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/openvr
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/par
     [Compiler] In file included from /root/lwjgl3-3.3.1/modules/lwjgl/par/src/generated/c/org_lwjgl_util_par_ParOctasphere.c:9:0:
     [Compiler] ../../../../modules/lwjgl/par/src/main/c/par_octasphere.h: В функции «paro_write_geodesic»:
     [Compiler] ../../../../modules/lwjgl/par/src/main/c/par_octasphere.h:227:5: ошибка: «for» loop initial declarations are only allowed in C99 mode
     [Compiler]      for (int point_index = 1; point_index < num_segments; point_index++, dst += 3) {
     [Compiler]      ^
     [Compiler] компиляция прервана из-за -Wfatal-errors.
     [Compiler] In file included from /root/lwjgl3-3.3.1/modules/lwjgl/par/src/generated/c/org_lwjgl_util_par_ParShapes.c:15:0:
     [Compiler] ../../../../modules/lwjgl/par/src/main/c/par_shapes.h: В функции «par_shapes__compute_welded_normals»:
     [Compiler] ../../../../modules/lwjgl/par/src/main/c/par_shapes.h:331:5: ошибка: «for» loop initial declarations are only allowed in C99 mode
     [Compiler]      for (int i = 0; i < m->npoints; i++, pdst += 3) {
     [Compiler]      ^
     [Compiler] компиляция прервана из-за -Wfatal-errors.
     [Compiler] In file included from /root/lwjgl3-3.3.1/modules/lwjgl/par/src/generated/c/org_lwjgl_util_par_ParStreamlines.c:14:0:
     [Compiler] ../../../../modules/lwjgl/par/src/main/c/par_streamlines.h: В функции «parsl_mesh_from_lines»:
     [Compiler] ../../../../modules/lwjgl/par/src/main/c/par_streamlines.h:296:5: ошибка: «for» loop initial declarations are only allowed in C99 mode
     [Compiler]      for (uint32_t spine = 0; spine < spines.num_spines; spine++) {
     [Compiler]      ^
     [Compiler] компиляция прервана из-за -Wfatal-errors.
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/remotery
          [gcc] Linking lwjgl_remotery
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/remotery
          [gcc] Linking lwjgl_opengles
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/opengles
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/rpmalloc
     [Compiler] In file included from /root/lwjgl3-3.3.1/modules/lwjgl/rpmalloc/src/generated/c/org_lwjgl_system_rpmalloc_RPmalloc.c:11:0:
     [Compiler] ../../../../modules/lwjgl/rpmalloc/src/main/c/rpmalloc.c:237:23: фатальная ошибка: stdatomic.h: Нет такого файла или каталога
     [Compiler]  #include <stdatomic.h>
     [Compiler]                        ^
     [Compiler] компиляция прервана.
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/sse
          [gcc] Linking lwjgl_sse
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/sse
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/stb
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/tinyexr
     [Compiler] g++: ошибка: unrecognized command line option «-std=gnu++14»
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/tinyfd
          [gcc] Linking lwjgl_opengl
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/opengl
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/tootle
     [Compiler] g++: ошибка: unrecognized command line option «-std=gnu++14»
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/vma
     [Compiler] g++: ошибка: unrecognized command line option «-std=gnu++14»
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/xxhash
          [gcc] Linking lwjgl_tinyfd
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/tinyfd
          [gcc] Linking lwjgl_xxhash
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/xxhash
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/yoga
     [Compiler] g++: ошибка: unrecognized command line option «-std=gnu++14»
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/linux/x64/zstd
          [gcc] Linking lwjgl_stb
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/stb
          [gcc] Linking lwjgl_zstd
        [mkdir] Created dir: /root/lwjgl3-3.3.1/bin/libs/native/linux/x64/org/lwjgl/zstd
    
    BUILD FAILED
    /root/lwjgl3-3.3.1/build.xml:565: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:166:
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:168: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:244: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:90: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:269: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:90: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:151: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:90: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:353: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:381: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:90: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:422: The following error occurred while executing this line:
    /root/lwjgl3-3.3.1/config/linux/build.xml:36: apply returned: 1
    
    Total time: 1 minute 32 seconds
    

    gcc 4.8, no stdatomic.h, no support for -std=gnu++14… Installed devtools-11 in /opt/rh/devtoolset-11/root/, so full path to gcc 11 is /opt/rh/devtoolset-11/root/usr/bin/gcc.

    How to say to ant where to search gcc?

    And I see one more error: Can't find glibconfig.h, but:

    $ find /usr/ -name glibconfig.h
    /usr/lib64/glib/include/glibconfig.h
    /usr/lib64/glib-2.0/include/glibconfig.h
    
    Type: Question 
    opened by VVD 0
  • Mac OS 13.1: libSystem.dylib not found

    Mac OS 13.1: libSystem.dylib not found

    Version

    3.3.1

    Platform

    macOS arm64

    JDK

    Java HotSpot(TM) 64-Bit Server VM v17.0.4.1+1-LTS-2 by Oracle Corporation

    Module

    LWJGL Core

    Bug description

    I try to do a simple LWJGL project, but on glfwInit I get the following error. It seems related to MacOS dynamic library. I will try to provide a minimal example if needed, but I think just calling glfwInit() suffices.

    Stacktrace or crash log output

    [LWJGL] Version: 3.3.1 build 7
    [LWJGL] 	 OS: Mac OS X v13.1
    [LWJGL] 	JRE: macOS aarch64 17.0.4.1
    [LWJGL] 	JVM: Java HotSpot(TM) 64-Bit Server VM v17.0.4.1+1-LTS-2 by Oracle Corporation
    [LWJGL] Loading JNI library: lwjgl
    [LWJGL] 	Module: org.lwjgl
    [LWJGL] 	Extracting: file:/Users/rongcuid/.gradle/caches/modules-2/files-2.1/org.lwjgl/lwjgl/3.3.1/71d0d5e469c9c95351eb949064497e3391616ac9/lwjgl-3.3.1-natives-macos-arm64.jar!/macos/arm64/org/lwjgl/liblwjgl.dylib
    [LWJGL] 	Loaded from org.lwjgl.librarypath: /var/folders/tw/8vsfcypj5rx4gbst7z5nrj7c0000gn/T/lwjglrongcuid/3.3.1-build-7/liblwjgl.dylib
    [LWJGL] Loading library: glfw
    [LWJGL] 	Module: org.lwjgl.glfw
    [LWJGL] 	Extracting: file:/Users/rongcuid/.gradle/caches/modules-2/files-2.1/org.lwjgl/lwjgl-glfw/3.3.1/cac0d3f712a3da7641fa174735a5f315de7ffe0a/lwjgl-glfw-3.3.1-natives-macos-arm64.jar!/macos/arm64/org/lwjgl/glfw/libglfw.dylib
    [LWJGL] 	Loaded from org.lwjgl.librarypath: /var/folders/tw/8vsfcypj5rx4gbst7z5nrj7c0000gn/T/lwjglrongcuid/3.3.1-build-7/libglfw.dylib
    [LWJGL] Loading library: objc
    [LWJGL] 	Module: org.lwjgl
    [LWJGL] 	libobjc.dylib not found in org.lwjgl.librarypath=/var/folders/tw/8vsfcypj5rx4gbst7z5nrj7c0000gn/T/lwjglrongcuid/3.3.1-build-7
    [LWJGL] Loading library: jemalloc
    [LWJGL] 	Module: org.lwjgl.jemalloc
    [LWJGL] 	Extracting: file:/Users/rongcuid/.gradle/caches/modules-2/files-2.1/org.lwjgl/lwjgl-jemalloc/3.3.1/e577b87d8ad2ade361aaea2fcf226c660b15dee8/lwjgl-jemalloc-3.3.1-natives-macos-arm64.jar!/macos/arm64/org/lwjgl/jemalloc/libjemalloc.dylib
    [LWJGL] 	Loaded from org.lwjgl.librarypath: /var/folders/tw/8vsfcypj5rx4gbst7z5nrj7c0000gn/T/lwjglrongcuid/3.3.1-build-7/libjemalloc.dylib
    [LWJGL] MemoryUtil allocator: JEmallocAllocator
    [LWJGL] Java 9 text decoding enabled
    [LWJGL] 	Loaded from system paths: /usr/lib/libobjc.A.dylib
    [LWJGL] Loading library: System
    [LWJGL] 	Module: org.lwjgl
    [LWJGL] 	libSystem.dylib not found in org.lwjgl.librarypath=/var/folders/tw/8vsfcypj5rx4gbst7z5nrj7c0000gn/T/lwjglrongcuid/3.3.1-build-7
    [LWJGL] 	Loaded from system paths: /usr/lib/libSystem.B.dylib
    Exception in thread "main" java.lang.ExceptionInInitializerError
    	at org.lwjgl.glfw.GLFW.glfwInit(GLFW.java:1046)
    	at eng.Window.<init>(Window.kt:18)
    	at eng.Window.<init>(Window.kt:10)
    	at eng.Engine.<init>(Engine.kt:16)
    	at MainKt.main(Main.kt:20)
    Caused by: java.lang.IllegalStateException: GLFW may only be used on the main thread and that thread must be the first thread in the process. Please run the JVM with -XstartOnFirstThread. This check may be disabled with Configuration.GLFW_CHECK_THREAD0.
    	at org.lwjgl.glfw.EventLoop.<clinit>(EventLoop.java:30)
    	... 5 more
    
    Type: Question 
    opened by rongcuid 3
  • Minecraft crash - LWJGL unable to locate liblwjgl.dylib

    Minecraft crash - LWJGL unable to locate liblwjgl.dylib

    Version

    3.3.1

    Platform

    macOS arm64

    JDK

    Zulu OpenJDK 19.0.1

    Module

    LWJGL core (natives)

    Bug description

    Was trying to launch Minecraft when LWJGL raised an error of Failed to load a library.. Looked down the crash log and found that the root issue was a java.lang.UnsatisfiedLinkError while java/LWJGL attempted to locate the liblwjgl.dylib.

    Any ideas?

    (The Java is 64-bit, but hasn't been signed as such. You'll notice the)

    Stacktrace or crash log output

    MultiMC version: 0.6.16-3434
    
    
    Launched instance in online mode
    
    authserver.mojang.com resolves to:
        [18.172.117.46, 18.172.117.34, 18.172.117.60, 18.172.117.47]
    
    session.minecraft.net resolves to:
        [34.197.32.8, 100.24.172.95, 35.153.153.200]
    
    textures.minecraft.net resolves to:
        [2620:1ec:bdf::51, 2620:1ec:46::51, 13.107.246.51, 13.107.213.51]
    
    api.mojang.com resolves to:
        [18.160.225.124, 18.160.225.73, 18.160.225.120, 18.160.225.40]
    
    
    Minecraft folder is:
    /Applications/MultiMC 2.app/Data/instances/omg rlly-/.minecraft
    
    
    Java path is:
    /usr/bin/java
    
    
    Checking Java version...
    Java is version 19.0.1, using 32-bit architecture, from Azul Systems, Inc..
    
    
    Your Java architecture is not matching your system architecture. You might want to install a 64bit Java version.
    
    
    Main Class:
      net.minecraft.client.main.Main
    
    Native path:
      /Applications/MultiMC 2.app/Data/instances/omg rlly-/natives
    
    Traits:
    traits XR:Initial
    traits FirstThreadOnMacOS
    
    Libraries:
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-glfw/3.3.1/lwjgl-glfw-3.3.1.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-jemalloc/3.3.1/lwjgl-jemalloc-3.3.1.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-openal/3.3.1/lwjgl-openal-3.3.1.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-opengl/3.3.1/lwjgl-opengl-3.3.1.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-stb/3.3.1/lwjgl-stb-3.3.1.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-tinyfd/3.3.1/lwjgl-tinyfd-3.3.1.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl/3.3.1/lwjgl-3.3.1.jar
      /Applications/MultiMC 2.app/Data/libraries/ca/weblite/java-objc-bridge/1.1/java-objc-bridge-1.1.jar
      /Applications/MultiMC 2.app/Data/libraries/com/github/oshi/oshi-core/6.2.2/oshi-core-6.2.2.jar
      /Applications/MultiMC 2.app/Data/libraries/com/google/code/gson/gson/2.10/gson-2.10.jar
      /Applications/MultiMC 2.app/Data/libraries/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar
      /Applications/MultiMC 2.app/Data/libraries/com/google/guava/guava/31.1-jre/guava-31.1-jre.jar
      /Applications/MultiMC 2.app/Data/libraries/com/ibm/icu/icu4j/71.1/icu4j-71.1.jar
      /Applications/MultiMC 2.app/Data/libraries/com/mojang/authlib/3.16.29/authlib-3.16.29.jar
      /Applications/MultiMC 2.app/Data/libraries/com/mojang/blocklist/1.0.10/blocklist-1.0.10.jar
      /Applications/MultiMC 2.app/Data/libraries/com/mojang/brigadier/1.0.18/brigadier-1.0.18.jar
      /Applications/MultiMC 2.app/Data/libraries/com/mojang/datafixerupper/5.0.28/datafixerupper-5.0.28.jar
      /Applications/MultiMC 2.app/Data/libraries/com/mojang/javabridge/2.0.25/javabridge-2.0.25.jar
      /Applications/MultiMC 2.app/Data/libraries/com/mojang/logging/1.1.1/logging-1.1.1.jar
      /Applications/MultiMC 2.app/Data/libraries/com/mojang/patchy/2.2.10/patchy-2.2.10.jar
      /Applications/MultiMC 2.app/Data/libraries/com/mojang/text2speech/1.13.9/text2speech-1.13.9.jar
      /Applications/MultiMC 2.app/Data/libraries/commons-codec/commons-codec/1.15/commons-codec-1.15.jar
      /Applications/MultiMC 2.app/Data/libraries/commons-io/commons-io/2.11.0/commons-io-2.11.0.jar
      /Applications/MultiMC 2.app/Data/libraries/commons-logging/commons-logging/1.2/commons-logging-1.2.jar
      /Applications/MultiMC 2.app/Data/libraries/io/netty/netty-buffer/4.1.82.Final/netty-buffer-4.1.82.Final.jar
      /Applications/MultiMC 2.app/Data/libraries/io/netty/netty-codec/4.1.82.Final/netty-codec-4.1.82.Final.jar
      /Applications/MultiMC 2.app/Data/libraries/io/netty/netty-common/4.1.82.Final/netty-common-4.1.82.Final.jar
      /Applications/MultiMC 2.app/Data/libraries/io/netty/netty-handler/4.1.82.Final/netty-handler-4.1.82.Final.jar
      /Applications/MultiMC 2.app/Data/libraries/io/netty/netty-resolver/4.1.82.Final/netty-resolver-4.1.82.Final.jar
      /Applications/MultiMC 2.app/Data/libraries/io/netty/netty-transport-classes-epoll/4.1.82.Final/netty-transport-classes-epoll-4.1.82.Final.jar
      /Applications/MultiMC 2.app/Data/libraries/io/netty/netty-transport-native-unix-common/4.1.82.Final/netty-transport-native-unix-common-4.1.82.Final.jar
      /Applications/MultiMC 2.app/Data/libraries/io/netty/netty-transport/4.1.82.Final/netty-transport-4.1.82.Final.jar
      /Applications/MultiMC 2.app/Data/libraries/it/unimi/dsi/fastutil/8.5.9/fastutil-8.5.9.jar
      /Applications/MultiMC 2.app/Data/libraries/net/java/dev/jna/jna-platform/5.12.1/jna-platform-5.12.1.jar
      /Applications/MultiMC 2.app/Data/libraries/net/java/dev/jna/jna/5.12.1/jna-5.12.1.jar
      /Applications/MultiMC 2.app/Data/libraries/net/sf/jopt-simple/jopt-simple/5.0.4/jopt-simple-5.0.4.jar
      /Applications/MultiMC 2.app/Data/libraries/org/apache/commons/commons-compress/1.21/commons-compress-1.21.jar
      /Applications/MultiMC 2.app/Data/libraries/org/apache/commons/commons-lang3/3.12.0/commons-lang3-3.12.0.jar
      /Applications/MultiMC 2.app/Data/libraries/org/apache/httpcomponents/httpclient/4.5.13/httpclient-4.5.13.jar
      /Applications/MultiMC 2.app/Data/libraries/org/apache/httpcomponents/httpcore/4.4.15/httpcore-4.4.15.jar
      /Applications/MultiMC 2.app/Data/libraries/org/apache/logging/log4j/log4j-api/2.19.0/log4j-api-2.19.0.jar
      /Applications/MultiMC 2.app/Data/libraries/org/apache/logging/log4j/log4j-core/2.19.0/log4j-core-2.19.0.jar
      /Applications/MultiMC 2.app/Data/libraries/org/apache/logging/log4j/log4j-slf4j2-impl/2.19.0/log4j-slf4j2-impl-2.19.0.jar
      /Applications/MultiMC 2.app/Data/libraries/org/joml/joml/1.10.5/joml-1.10.5.jar
      /Applications/MultiMC 2.app/Data/libraries/org/slf4j/slf4j-api/2.0.1/slf4j-api-2.0.1.jar
      /Applications/MultiMC 2.app/Data/libraries/com/mojang/minecraft/1.19.3/minecraft-1.19.3-client.jar
    
    Native libraries:
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-glfw/3.3.1/lwjgl-glfw-3.3.1-natives-macos.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-jemalloc/3.3.1/lwjgl-jemalloc-3.3.1-natives-macos.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-openal/3.3.1/lwjgl-openal-3.3.1-natives-macos.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-opengl/3.3.1/lwjgl-opengl-3.3.1-natives-macos.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-stb/3.3.1/lwjgl-stb-3.3.1-natives-macos.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl-tinyfd/3.3.1/lwjgl-tinyfd-3.3.1-natives-macos.jar
      /Applications/MultiMC 2.app/Data/libraries/org/lwjgl/lwjgl/3.3.1/lwjgl-3.3.1-natives-macos.jar
    
    Params:
      --username  --version 1.19.3 --gameDir /Applications/MultiMC 2.app/Data/instances/omg rlly-/.minecraft --assetsDir /Applications/MultiMC 2.app/Data/assets --assetIndex 2 --uuid  --accessToken  --userType  --versionType release
    
    Window size: 854 x 480
    
    Java Arguments:
    [-Dorg.lwjgl.util.DebugLoader=true, -Dorg.lwjgl.librarypath=/Applications/MultiMC 2/Data/Instances/omg rlly-/.minecraft/libraries, -Xdock:icon=icon.png, -Xdock:name="MultiMC: omg rlly?", -XstartOnFirstThread, -Xms3072m, -Xmx3072m, -Duser.language=en]
    
    
    Minecraft process ID: 18552
    
    
    Using onesix launcher.
    
    [11:44:11] [main/INFO]: Building optimized datafixer
    [11:44:13] [Render thread/INFO]: [STDERR]: [LWJGL] Failed to load a library. Possible solutions:
    	a) Add the directory that contains the shared library to -Djava.library.path or -Dorg.lwjgl.librarypath.
    	b) Add the JAR that contains the shared library to the classpath.
    [11:44:13] [Render thread/INFO]: [STDERR]: [LWJGL] Enable debug mode with -Dorg.lwjgl.util.Debug=true for better diagnostics.
    [11:44:13] [Render thread/INFO]: [STDERR]: Failed to start Minecraft:
    [11:44:13] [Render thread/INFO]: [STDERR]: java.lang.reflect.InvocationTargetException
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:119)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at java.base/java.lang.reflect.Method.invoke(Method.java:578)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at org.multimc.onesix.OneSixLauncher.launchWithMainClass(OneSixLauncher.java:210)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at org.multimc.onesix.OneSixLauncher.launch(OneSixLauncher.java:245)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at org.multimc.EntryPoint.listen(EntryPoint.java:143)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at org.multimc.EntryPoint.main(EntryPoint.java:34)
    [11:44:13] [Render thread/INFO]: [STDERR]: Caused by: java.lang.NoClassDefFoundError: Could not initialize class com.mojang.blaze3d.systems.RenderSystem
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at z.a(SourceFile:66)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at ejf.a(SourceFile:2408)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at ejf.a(SourceFile:2403)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at net.minecraft.client.main.Main.a(SourceFile:214)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at net.minecraft.client.main.Main.main(SourceFile:51)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	... 5 more
    [11:44:13] [Render thread/INFO]: [STDERR]: Caused by: java.lang.ExceptionInInitializerError: Exception java.lang.UnsatisfiedLinkError: Failed to locate library: liblwjgl.dylib [in thread "Render thread"]
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.Library.loadSystem(Library.java:164)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.Library.loadSystem(Library.java:63)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.Library.<clinit>(Library.java:51)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at org.lwjgl.system.MemoryUtil.<clinit>(MemoryUtil.java:100)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at edb.<clinit>(SourceFile:8)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at edy.<init>(SourceFile:51)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at eef.<init>(SourceFile:19)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at eef.<init>(SourceFile:23)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at eef.<clinit>(SourceFile:11)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at com.mojang.blaze3d.systems.RenderSystem.<clinit>(SourceFile:46)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	at net.minecraft.client.main.Main.a(SourceFile:202)
    [11:44:13] [Render thread/INFO]: [STDERR]: 	... 7 more
    [11:44:13] [Render thread/INFO]: [STDOUT]: Exiting with -1
    Process exited with code 255 (0xff).
    Please note that usually neither the exit code, nor its description are enough to diagnose issues!
    Always upload the entire log and not just the exit code.
    Clipboard copy at: 20 Dec 2022 11:45:28 -0600
    Clipboard copy at: 20 Dec 2022 11:49:48 -0600
    
    Type: Question 
    opened by meawplex-plus 7
  • "Invalid value for parameter" error in the latest snapshot build

    Version

    3.3.2 (nightly)

    Platform

    Linux x64

    JDK

    Adoptium OpenJDK 19

    Module

    LWJGL Core, GLFW

    Bug description

    Hi,

    After upgrading to LWJGL 3.3.2-snapshot+8 I am getting this error when running my project. I am using jMonkeyEngine.

    It works fine in the LWJGL 3.3.2-snapshot+7 and older versions.

    Stacktrace or crash log output

    18:02:50,890 ERROR [LegacyApplication] Invalid value for parameter
    java.lang.Exception: Invalid value for parameter
    	at com.jme3.system.lwjgl.LwjglWindow$1.invoke(LwjglWindow.java:229) [jme3-lwjgl3-3.6.0-SNAPSHOT.jar:3.6.0-SNAPSHOT]
    	at org.lwjgl.glfw.GLFWErrorCallbackI.callback(GLFWErrorCallbackI.java:43) [lwjgl-glfw-3.3.2-SNAPSHOT.jar:build 8]
    	at org.lwjgl.system.JNI.invokeI(Native Method) ~[lwjgl-3.3.2-SNAPSHOT.jar:build 8]
    	at org.lwjgl.glfw.GLFW.glfwInit(GLFW.java:1071) [lwjgl-glfw-3.3.2-SNAPSHOT.jar:build 8]
    	at com.jme3.system.lwjgl.LwjglWindow.createContext(LwjglWindow.java:233) [jme3-lwjgl3-3.6.0-SNAPSHOT.jar:3.6.0-SNAPSHOT]
    	at com.jme3.system.lwjgl.LwjglWindow.initInThread(LwjglWindow.java:582) [jme3-lwjgl3-3.6.0-SNAPSHOT.jar:3.6.0-SNAPSHOT]
    	at com.jme3.system.lwjgl.LwjglWindow.run(LwjglWindow.java:704) [jme3-lwjgl3-3.6.0-SNAPSHOT.jar:3.6.0-SNAPSHOT]
    	at java.lang.Thread.run(Thread.java:1589) [?:?]
    18:02:52,590 INFO  [LwjglContext] LWJGL 3.3.2-snapshot+8 context running on thread jME3 Main
     * Graphics Adapter: GLFW 3.4.0 Wayland X11 GLX Null EGL OSMesa monotonic shared
    18:02:53,022 INFO  [GLRenderer] OpenGL Renderer Information
     * Vendor: X.Org
     * Renderer: AMD CEDAR (DRM 2.50.0 / 5.4.0-58-generic, LLVM 10.0.0)
     * OpenGL Version: 3.3 (Core Profile) Mesa 20.0.8
     * GLSL Version: 3.30
     * Profile: Core
    
    Type: Maintenance 
    opened by Ali-RS 3
  • Java port of vulkan-tutorial.com shows a black screen on specifically a AMD RX 6600

    Java port of vulkan-tutorial.com shows a black screen on specifically a AMD RX 6600

    Version

    3.3.1

    Platform

    Windows x64

    JDK

    jdk-17.0.5.8-hotspot

    Module

    Vulkan

    Bug description

    Hi,

    I'm working on an extended version of the 'official' Java port of vulkan-tutorial.com. When swapping my AMD RX 570 for a AMD RX 6600, and running the code the (glfw) window remains black.

    I've check a lot of stuff. Can anybody help me what to look for? Or reproduce and confirming the same issue?

    When looking for or ruling out a possible cause, the following have been checked:

    • there are no errors reported.
    • the initial base chapters of the Java port. All giving me a black window.
    • the GPU is working. In use 10% looking at the task manager, and with vsync disabled (VK_PRESENT_MODE_IMMEDIATE_KHR) ramping up to 85%.
    • The original C++ version (https://vulkan-tutorial.com/code/15_hello_triangle.cpp) does work.
    • The demos on https://github.com/LWJGL/lwjgl3-demos/tree/main/src/org/lwjgl/demo/vulkan do work.
    • My two desktops (AMD Phenom II and Intel I5 10400) are giving the same result, swapping the GPU's, the RX6600 giving a black window on both machines with exact same software and versions on it.
    • reinstalling windows.
    • making sure latest releases are used.
    • Checked with the author of the code, but can't reproduce the issue on a Nvidea RTX 3080
    • changing the clearColor to blue, but still giving a black screen?!
    • Trying to align base code of almost the exact same output (a colored triangle), but in my learning curve no obvious issue is found. issue: https://github.com/Naitsirc98/Vulkan-Tutorial-Java/blob/master/src/main/java/javavulkantutorial/Ch15HelloTriangle.java working: https://github.com/LWJGL/lwjgl3-demos/blob/main/src/org/lwjgl/demo/vulkan/ColoredTriangleDemo.java
    • plugged the RX 570 in an not reinstalling any driver, the issue is gone!!!

    My best guess it's a specific bug caused in mixture of something:

    • in the drivers for the new GPU architecture
    • combined with usage of LWJGL
    • the approach of vulkan methods in the source code.

    Reproducible with the code on the url below (chapter Ch15HelloTriangle.java for instance) https://github.com/Naitsirc98/Vulkan-Tutorial-Java/tree/master/src/main/java/javavulkantutorial

    with latest releases: VulkanSDK 1.3.231.1 AMD drivers 22.11.2 jdk-17.0.5.8-hotspot lwjgl 3.3.1 VSCode 1.74.1

    Stacktrace or crash log output

    No response

    opened by Trunkvv 12
Releases(3.3.1)
  • 3.3.1(Feb 21, 2022)

    Changes since 3.3.0:

    Bindings

    • Added liburing bindings.
      • Can be found in the LWJGL core module (package org.lwjgl.system.linux.liburing).
    • Added OpenXR bindings. (#569)
    • Assimp: Updated to 5.2.2 (up from 5.1.0)
    • glfw: Updated to latest 3.3.6 (up from 3.3.5)
      • Added glfwGetGLXFBConfig.
      • Added glfwGetEGLConfig.
    • meshoptimizer: Updated to 0.17 (up from 0.16)
    • Nuklear: Updated to 4.9.6 (up from 4.09.0)
    • Shaderc: Updated to 2022.1 (up from 2021.3)
    • vma: Updated to latest 3.3.0-development
      • Added virtual allocator API.
      • Added VMA_MEMORY_USAGE_AUTO.
    • Vulkan: Updated to 1.3.206 (up from 1.2.198)
      • Includes MoltenVK 1.1.7 (up from 1.1.5)
    • xxhash: Updated to 0.8.1 (up from 0.8.0)
    • Zstd: Updated to 1.5.2 (up from 1.5.0)
      • Also, the LWJGL memory allocator is now used for internal allocations.

    Improvements

    • GLFW: An alternative macOS build now supports Cocoa calls on any thread.
      • A different window toolkit (AWT, JavaFX, etc.) may now run at the same time as GLFW. It must be initialized before glfwInit is called.
      • Enabled with Configuration.GLFW_LIBRARY_NAME.set("glfw_async");.

    Fixes

    • Core: Fixed extra NUL in string returned from SharedLibrary::getPath() on Linux & macOS. (#713)
    • Core: Fixed integer overflow when casting pointers on 32-bit architectures. (#720)
    • Core: Fixed rare NPE with Configuration.DEBUG_STACK enabled. (#721)
    • OpenCL: Fixed values of the KERNEL_ARG_ADDRESS_* constants. (#733)
    • OpenCL: Fixed value of KERNEL_ARG_TYPE_QUALIFIER constant. (#735)
    • vma: Fixed nullability of VmaVirtualAllocationCreateInfo::pUserData member.
    • Vulkan: All noautovalidity parameters/members are now regarded as nullable. (#702)
    Source code(tar.gz)
    Source code(zip)
    lwjgl.zip(146.12 MB)
  • 3.3.0(Nov 15, 2021)

    Changes since 3.2.3:

    Bindings

    • Added libffi bindings.
      • Bundled with the LWJGL core, under the org.lwjgl.system package.
    • Added meshoptimizer bindings.
    • Added SPIRV-Cross bindings.
    • Assimp: Updated to 5.1.0 (up from 5.0.0.rc2)
    • bgfx: Updated to API version 115 (up from 100)
    • CUDA: Updated to 11.5.0 (up from 10.1.0)
      • Now includes full API documentation.
    • glfw: Updated to latest 3.3.4 (up from 3.3.1):
      • Added GLFW_WIN32_KEYBOARD_MENU.
      • Added GLFW_CURSOR_UNAVAILABLE.
      • Added GLFW_FEATURE_UNAVAILABLE.
      • Added GLFW_FEATURE_UNIMPLEMENTED.
      • Added GLFW_MOUSE_PASSTHROUGH.
      • Added GLFW_ANGLE_PLATFORM_TYPE.
      • Added GLFW_CONTEXT_DEBUG.
      • Added GLFW_X11_XCB_VULKAN_SURFACE.
      • Added GLFW_PLATFORM, GLFW_PLATFORM_UNAVAILABLE.
      • Added GLFW_ANY_PLATFORM, GLFW_PLATFORM_WIN32, GLFW_PLATFORM_COCOA, GLFW_PLATFORM_WAYLAND, GLFW_PLATFORM_X11, GLFW_PLATFORM_NULL.
      • Added glfwInitAllocator.
      • Added glfwGetPlatform.
      • Added glfwPlatformSupported.
      • Added glfwInitVulkanLoader.
      • Added standard cursors for diagonal and omnidirectional resize/move and operation-not-allowed.
      • Added OSMesa native access functions.
    • LibOVR: Updated to 1.64.0 (up from 1.39.0)
    • libdivide: Updated to 5.0 (up from 2.0)
      • Added support for 16-bit divisions.
    • LLVM/Clang: Updated to 13.0.1 (up from 8.0)
    • lmdb: Updated to 0.9.28 (up from 0.9.24)
    • lz4: Updated to 1.9.3 (up from 1.9.2)
    • NativeFileDialog: Updated to 1.2.0 (up from 1.1.6)
    • Nuklear: Updated to 4.09.0 (up from 4.01.0)
    • OpenAL Soft: Updated to 1.21.1 (up from 1.19.1)
      • Added AL_SOFT_bformat_ex extension.
      • Added AL_SOFT_buffer_samples extension.
      • Added AL_SOFT_buffer_sub_data extension.
      • Added AL_SOFT_direct_channels_remix extension.
    • OpenCL: Added support for OpenCL 3.0.
    • OpenVR: Updated to 1.16.8 (up from 1.6.10)
    • Opus: Added Opusfile & Libopusenc bindings (#634)
    • par: Added par_octasphere bindings.
    • rpmalloc: Updated to 1.4.3 (up from 1.4.0)
    • Shaderc: Updated to 2021.3 (up from 2019.1)
    • stb
      • Updated stb_dxt to 1.12 (up from 1.08)
      • Updated stb_easy_font to 1.1 (up from 1.0)
      • Updated stb_image to 2.27 (up from 2.23)
      • Updated stb_image_resize to 0.97 (up from 0.96)
      • Updated stb_image_write to 1.16 (up from 1.13)
      • Updated stb_perlin to 0.5 (up from 0.4)
      • Updated stb_rect_pack to 1.01 (up from 1.00)
      • Updated stb_truetype to 1.26 (up from 1.22)
      • Updated stb_vorbis to 1.22 (up from 1.17)
    • tinyexr: Updated to 1.0.1 (up from 1.0.0 pre-release)
    • tinyfiledialogs: Updated to 3.8.8 (up from 3.3.9)
    • vma: Updated to 3.3.0-development (up from 2.2.0)
    • Vulkan: Updated to 1.2.198 (up from 1.1.121)
      • Includes Vulkan Video
      • Includes MoltenVK 1.1.5 (up from 1.0.36)
    • xxhash: Updated to 0.8.0 (up from 0.7.1)
    • Yoga: Updated to 1.19.0 (up from 1.14.0)
    • Zstd: Updated to 1.5.0 (up from 1.4.3)

    Improvements

    • macOS/Windows: Added support for ARM builds. (#601)
      • Maven classifier for macOS: natives-macos-arm64
      • Maven classifier for Windows: natives-windows-arm64
    • Linux: Shared libraries are now built with GCC 7.5 (up from GCC 4.8)
    • Generator: Struct member javadoc moved to the corresponding getter method.
      • There are links to the getter method in the class javadoc (Layout section) and in the javadoc of the corresponding setter and .Buffer accessors.
      • Makes it easier to navigate to the documentation of a particular member.
    • Generator: simplified stack allocation methods in Struct classes.
      • 4 new methods added, named malloc and calloc, without a "Stack" suffix.
      • 8 old methods with the "Stack" suffix are now deprecated, to be removed in LWJGL 3.4.0.
    • Core: Replaced internal usages of dyncall with libffi.
      • This resolves a range of long-standing issues, mainly with upcalls (callbacks).
      • Single native callback handler used for all upcalls, regardless of signature. Arguments and return values handled Java-side (per callback type).
      • Improved upcall performance (before: JNI downcall per argument, after: simple memory accesses)
      • Support for structs returned by-value. (#283)
    • Core: Implemented overflow protection in text encoding methods.
    • Core: When LWJGL fails to resolve native libraries, it will now attempt to report native JAR files in the classpath with mismatching platform/architecture. (#587)
    • Core: The SharedLibraryLoader now prefers to extract natives to the working directory, over the user's home directory.
    • Core: Added version information to module descriptors. (#685)
      • The LWJGL version/build used will now be included in stacktraces of modular applications.
    • docs: The javadoc of callback classes/interfaces now includes a link to the corresponding invoke method, for better IDE navigation.
    • macOS: Shared libraries are now built with Xcode 11.3 (up from 10.0)
    • GLFW: Added overrides for internally loaded shared libraries.
      • Useful when there's a mismatch with the library loaded by LWJGL.
      • GLFWNativeEGL.setEGLPath & GLFWNativeEGL.setGLESPath
      • GLFWNativeGLX.setPath
      • GLFWNativeNSGL.setFramework
      • GLFWNativeWGL.setPath
      • GLFWVulkan.setPath
    • GLFW: There is now a single Linux native that supports both X11 and Wayland.
      • Use glfwPlatformSupported(GLFW_PLATFORM_WAYLAND) to test if Wayland is available.
      • Use glfwInitHint(GLFW_PLATFORM, GLFW_PLATFORM_WAYLAND) to enable the Wayland backend.
    • GL: Added support for OSMesa contexts. (#595)
    • GL/GLES/AL: Added createCapabilities overloads that accept an IntFunction<PointerBuffer>. Enables explicit management of the off-heap memory used by the capabilities instances.
    • GL/GLES/AL: When capabilities creation fails, the current thread/process capabilities state is no longer reset to null.
    • GL/GLES/AL/CL/EGL: Added Configuration options to forcibly disable specific extensions for debugging purposes. (#683)
    • OpenAL: Introduced ALC::setCapabilities. Rarely useful when opening multiple devices with different ALC capabilities. (#582)
    • Vulkan: Struct classes now include an additional sType setter that writes the appropriate struct type value. (#537)
    • Vulkan: Struct classes now include type-safe pNext setters, one for each struct type that is known to extend them.
      • These setters prepend the struct to the pNext chain, enabling cleaner code when chaining multiple structs.
      • Order does not matter, but do note that structs will be chained in the reverse order of the pNext calls.
      • Also be careful when the base struct is malloced, make sure to call .pNext(NULL) first, otherwise the last struct in the chain will point to invalid memory.

    Fixes

    • Generator: Native libraries are now initialized before constants. (#630)
    • Core: Fixed unsafe field reads in MemoryUtil setup code. (#632)
    • Core: The SharedLibraryLoader now prepends a . to SHARED_LIBRARY_EXTRACT_DIRECTORY when the target directory is not temporary.
    • Core: The SharedLibraryLoader will now load libraries in the correct ClassLoader when testing for JDK-8195129. (#648)
    • Core: Changed the encoding of dlopen paths to UTF-8. (#691)
    • CUDA: Implemented missing cuIpcOpenEventHandle/cuIpcOpenMemHandle using libFFI.
    • EGL: Fixed nullability of eglInitialize arguments.
    • GLFW: Fixed main thread check. Setting GLFW_CHECK_THREAD0 to false is now required for offscreen interop. (#538)
    • OpenCL: Added missing errcode_ret parameter to clLinkProgram. (#560)
    • OpenGL: Restored GL_TEXTURE in the core profile. (#573)
    • OpenGL: Added buffer object offset overloads to GetQueryObject* functions.
    • stb: Removed redundant stb_image_resize overloads. (#605)
    • Vulkan: Fixed GLFW configuration for MoltenVK. (#502)
    • Vulkan: Fixed vkGetInstanceProcAddr to work with null instance arguments.
    • Vulkan: Fixed unsigned arithmetic in VK_VERSION_MAJOR and VK_VERSION_MINOR macros.

    Breaking Changes

    (B): binary incompatible change
    (S): source incompatible change
    
    • Linux: Shared libraries are now built on Ubuntu 18.04 (up from Ubuntu 16.04) (B)
      • GLIBC versions older than 2.14 are no longer supported. Some, but not all, LWJGL natives may require up to GLIBC 2.27.
      • Applications deployed on older systems must now build & bundle custom LWJGL natives. Contact LWJGL developers if you need assistance.
    • Removed deprecated methods that were marked for removal in LWJGL 3.3. (S)
    • Core: Users of the dyncall bindings must migrate to libffi. (S)
    • CUDA: Merged versioned classes into a single class that contains the entire functionality. (S)
      • The bindings still require CUDA 3.2 as the minimum version. There are runtime checks for functions introduced after 3.2.
    • Shaderc: The shaderc_spvc library has been removed since Shaderc 2020.4. Users may migrate to the new SPIRV-Cross bindings. (S)
    • Vulkan: All header boilerplate constants have been moved to VK10. (S)
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.3.0.zip(136.61 MB)
  • 3.2.3(Sep 1, 2019)

    Changes since 3.2.2:

    Bindings

    • Added Shaderc bindings. (#77)
    • Added bindings to platform APIs that can be used to programmatically generate input events.
    • Assimp: Updated to 5.0.0rc2 (up from 5.0.0rc1).
    • bgfx: Updated to API version 100 (up from 99)
    • glfw: Updated to 3.4.0 pre-release (up from 3.3.0)
    • EGL: Added EGL_NV_stream_dma.
    • jemalloc: Updated to 5.2.1 (up from 5.2.0)
    • LibOVR: Updated to 1.39.0 (up from 1.35.0)
    • libdivide: Updated to 2.0 (up from 1.0)
    • lz4: Updated to 1.9.2 (up from 1.9.1)
      • Also, the LWJGL memory allocator is now used for internal allocations.
    • nuklear: Updated to 4.01.0 (up from 4.00.2)
    • OpenGL(ES): Added latest extensions.
      • GL_EXT_multiview_tessellation_geometry_shader
      • GL_EXT_multiview_texture_multisample
      • GL_EXT_multiview_timer_query
      • GL_EXT_texture_shadow_lod
      • GL_EXT_texture_sRGB_R8
      • GL_KHR_shader_subgroup
      • GL_NV_shader_subgroup_partitioned
      • GL_NVX_gpu_multicast2
      • GL_NVX_progress_fence
    • OpenVR: Updated to 1.6.10 (up from 1.3.22)
    • par: Updated par_shapes to latest version.
      • Added par_shapes_create_cone.
    • par: Added par_streamlines bindings.
    • rpmalloc: Updated to 1.4.0 (up from 1.3.2)
    • stb
      • Updated stb_image to 2.23 (up from 2.22)
      • Updated stb_truetype to 1.22 (up from 1.21)
      • Updated stb_vorbis to 1.17 (up from 1.16)
    • Vulkan: Updated to 1.1.121 (up from 1.0.107)
      • Includes MoltenVK 1.0.36
    • xxhash: Updated to 0.7.1 (up from 0.7.0)
    • Zstd: Updated to 1.4.3 (up from 1.4.0)

    Improvements

    • Linux: Added support for ARM builds.
      • 32-bit: ARMv7/armhf architecture. Maven classifier: linux-arm32
      • 64-bit: ARMv8/AArch64 architecture. Maven classifier: linux-arm64
    • Windows: There is now a separate native JAR file per architecture.
      • The default contains x64 shared libraries only. Maven classifier: windows
      • lwjgl-natives-windows-x86.jar contains x86 shared libraries only. Maven classifier: windows-x86
      • The 32 suffix has been dropped from x86 shared library names.
    • Windows: Shared libraries are now built with Visual Studio 2019 (up from 2017)
    • Maven: LWJGL artifacts now include a Bill of Materials (lwjgl-bom). (#481)
    • Refactored the layout of native JAR files.
      • Shared libraries have been moved from the root to a <platform>/<arch>/<module>/ subfolder.
        • <platform>: one of linux, macos, windows.
        • <arch>: one of x64, x86, arm64, arm32.
        • <module>: the corresponding Java module name as a package hierarchy.
        • Example: glfw.so in lwjgl-glfw-natives-linux.jar is under the linux/x64/org/lwjgl/glfw folder.
      • The new layout allows multiple native JAR files to be combined for custom deployment.
      • Custom (or the old) layout may be used with newly exposed Configuration options.
    • Core: Added enum Platform.Architecture and Platform.getArchitecture() API.
    • Core: Added relative & absolute apply(Consumer<T>) methods to StructBuffer<T>.
    • Core: Added Consumer<T> setters to structs with nested arrays of structs.
    • Core: Added memByteBuffer overloads that return ByteBuffer views of other buffer types.
    • Core: Added CLongBuffer, a class similar to PointerBuffer but for C long values.

    Fixes

    • Core: Removed support for Critical JNI Natives. (#490)
      • Will be restored in LWJGL 3.3 (disabled by default, enabled with a Configuration option).
    • Core: Fixed buffer attachment offset detection on JDK 12+. (#491)
    • Core: Fixed ByteBuffer attachments in memSlice & memDuplicate.
    • Generator: Fixed invalid generation of functions with struct parameters passed by value. (#496)
      • Affected bindings: OpenVR and LLVM/Clang.
    • Generator: Improved javadoc for array and nested struct members.
    • EGL/GLES: Fixed bootstrapping code.
      • Regression caused by org.lwjgl.system.JNI refactoring in 3.2.2.
    • LLVM: Fixed default library names.
    • lmdb: Reverted to the official release. (#482)
      • Windows: Performance issues are eliminated, but sparse database mappings & incremental file growth are not supported anymore.
    • OpenGL: Fixed signatures of glGetnUniformiv and glGetnUniformuiv.

    Breaking Changes

    (B): binary incompatible change
    (S): source incompatible change
    
    • Core: The Library.loadSystem & Library.loadNative methods now require a module name parameter. (S)
    • Core: Removed Consumer<T> overloads from read-only structs with nested struct members. (S)
    • Core: MemoryUtil.memFree(PointerBuffer) changed to memFree(CustomBuffer). (B)
    • LZ4: The autoFlush and favorDecSpeed members of LZ4F_preferences_t are now mapped to Java boolean. (S)
    • Vulkan: The descriptorCount member of VkWriteDescriptorSet must now be set explicitly. (S)
      • The semantics of descriptorCount may change via extensions, which invalidates auto-sizing.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.2.3.zip(108.23 MB)
  • 3.2.2(May 5, 2019)

    Changes since 3.2.1:

    Bindings

    • bgfx: Updated to API version 99 (up from 90)
    • glfw: Updated to 3.3.0 (up from 3.3.0 pre-release):
      • Added GLFW_RAW_MOUSE_MOTION.
      • Added glfwGetMonitorWorkarea.
      • Added glfwRawMouseMotionSupported.
    • CUDA: Updated to 10.1 (up from 10.0)
    • jemalloc: Updated to 5.2.0 (up from pre-release 5.2.0)
    • LibOVR: Updated to 1.35.0 (up from 1.31.0)
    • LLVM/Clang: Updated to 8.0 (up from 7.0)
    • lmdb: Updated to 0.9.24 (up from 0.9.23)
    • lz4: Updated to 1.9.1 (up from 1.8.3)
    • NanoVG: Added support for using bgfx as the rendering back-end.
    • NanoVG: Added Blendish & OUI bindings.
    • NativeFileDialog: Updated to 1.1.4 (up from 1.1.3)
    • OpenVR: Updated to 1.3.22 (up from 1.1.3b)
    • Opus: Updated to 1.3.1 (up from 1.3.0)
    • stb
      • Updated stb_image to 2.22 (up from 2.19)
      • Updated stb_image_resize to 0.96 (up from 0.95)
      • Updated stb_image_write to 1.13 (up from 1.09)
      • Updated stb_perlin to 0.4 (up from 0.3)
      • Updated stb_rect_pack to 1.00 (up from 0.11)
      • Updated stb_truetype to 1.21 (up from 1.19)
      • Updated stb_vorbis to 1.16 (up from 1.14)
    • tinyfiledialogs: Updated to 3.3.9 (up from 3.3.8)
    • vma: Updated to 2.2.0 (up from 2.1.0)
    • Vulkan: Updated to 1.1.107 (up from 1.0.95)
      • Includes MoltenVK 1.0.35 (up from 1.0.27)
    • xxhash: Updated to 0.7.0 (up from 0.6.5)
    • Yoga: Updated to 1.14.0 (up from 1.10.0)
    • Zstd: Updated to 1.4.0 (up from 1.3.7)

    Improvements

    • build(ant): The release target now works in offline mode (LWJGL_BUILD_OFFLINE=true).
      • The build can be incomplete. Missing natives will be ignored and javadoc generation can be disabled for faster builds.
    • build(gradle): Deployments of incomplete builds to the local Maven repository are now allowed.
    • Core: Implemented workaround for JDK-8195129 in the SharedLibraryLoader.
    • perf: Critical JNI Natives are now generated for primitive-only functions.
    • LLVM: The bindings can now be used with LLVM/Clang version 5.0 or newer (down from 8.0).

    Fixes

    • build(ant): Fixed building on Linux & macOS when the path to LWJGL's root directory is shallow. (#442)
    • Core: Fixed race condition in callback deallocation when the debug allocator is enabled. (#444)
    • Generator: The workaround for JDK-8167409 is now applicable to functions with 5 parameters + 1 implicit parameter (function address or struct value result).
    • Generator: Support void() in callback functions without parameters.
    • Assimp: Added missing members to various struct types.
    • LLVM: LLVMGetErrorMessage now returns ByteBuffer instead of String, so that LLVMDisposeErrorMessage can be used.
    • nuklear: The nk_text_edit, nk_text_undo_state and nk_text_undo_record structs are now public.
    • OpenCL: Array overloads of EnqueueRead/Write functions cannot be used to perform non-blocking reads/writes anymore.
    • OpenGL: Added GL_DRAW_INDIRECT_BUFFER overloads to NV_bindless_multi_draw_indirect & NV_bindless_multi_draw_indirect_count extensions.
    • vma: Fixed VmaMemoryUsage enumeration values. (#458)

    Breaking Changes

    (B): binary incompatible change
    (S): source incompatible change
    
    • Core: Function address parameters in org.lwjgl.system.JNI & org.lwjgl.system.jawt.JAWTFunctions methods are now last, after normal parameters. (S)
      • Enables tail-calls without argument shuffling, when Critical JNI Natives are used.
    • glfw: removed CharSequence overload of glfwUpdateGamepadMappings. (S) (#462)

    Known Issues

    • Core: LWJGL 3.2.2 is incompatible with Java 12 or higher. (#491)
      • This issue is fixed in LWJGL 3.2.3.
    • Core: Using LWJGL 3.2.2 with a garbage collector that does not support object pinning, may lead to excessive GC-related blocking. (#490)
      • Workaround: pass -XX:-CriticalJNINatives to the JVM.
      • This issue is fixed in LWJGL 3.2.3.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.2.2.zip(75.21 MB)
  • 3.2.1(Dec 8, 2018)

    Changes since 3.2.0:

    Bindings

    • Added CUDA bindings.
      • Only the Driver API & NVRTC are supported in this release.
      • Bindings to more CUDA Toolkit libraries will be added in the future.
    • Added libdivide bindings.
    • Added LLVM/Clang bindings.
      • LLVM binaries are not included in this release. They must be separately downloaded or built for each platform.
    • Added Meow hash bindings.
    • Added Opus bindings.
    • bgfx: Updated to API version 90 (up from 76)
    • dyncall: Updated to 1.0 (up from 1.0-RC)
    • glfw: Updated to pre-release 3.3.0 version (up from 3.3.0 pre-release):
      • Added GLFW_SCALE_TO_MONITOR.
      • Added glfwAttachWin32Window. (experimental)
    • jemalloc: Updated to pre-release 5.2.0 (up from 5.1.0)
      • When available, it is again the default memory allocator on Windows.
    • LibOVR: Updated to 1.30.0 (up from 1.26.0)
    • lz4: Updated to 1.8.3 (up from 1.8.2)
    • Nuklear: Updated to 4.00.2 (up from 4.00.1)
    • OpenAL Soft: Updated to 1.19.1 (up from 1.18.2)
      • Added ALC_SOFT_device_clock extension.
    • OpenGL(ES): Added latest extensions:
      • NV_memory_attachment
      • NV_compute_shader_derivatives
      • NV_fragment_shader_barycentric
      • NV_mesh_shader
      • NV_representative_fragment_test
      • NV_scissor_exclusive
      • NV_shader_texture_footprint
      • NV_shading_rate_image
      • QCOM_shader_framebuffer_fetch_rate
      • QCOM_texture_foveated_subsampled_layout
    • OpenVR: Updated to 1.1.3b (up from 1.0.16)
    • rpmalloc: Updated to 1.3.2 (up from 1.3.1)
    • tinyfiledialogs: Updated to 3.3.8 (up from 3.3.6)
    • vma: Updated to 2.1.0 (up from 2.0.0)
    • Vulkan: Updated to 1.1.95 (up from 1.0.82)
      • Includes MoltenVK 1.0.27 (up from 1.0.16)
    • Yoga: Updated to 1.10.0 (up from 1.9.0)
    • Zstd: Updated to 1.3.7 (up from 1.3.5)

    Improvements

    • perf(core): Refactored LWJGL internals to make call stacks shallower.
      • Makes it harder to cross Hotspot's default MaxInlineLevel threshold, which can disable important optimizations.
    • perf(core): Added memDuplicate and refactored memSlice with implementations that use Unsafe to construct buffer instances, similar to mem-X-Buffer.
      • Compared to the default JDK implementations, these methods are faster and enable Scalar Replacement via EA on Hotspot.
      • The memSlice with offset method is also thread-safe now.
    • perf(core): Implemented workarounds to make struct buffer iteration garbage free on Hotspot.
    • perf(core): Re-tuned string codecs and memCopy/memSet for Java versions 8 to 11.
    • perf(core): Added thread-local array cache to minimize allocations while decoding text.
    • bgfx: Builds of bgfx tools (geometryc, shaderc, texturec, texturev) are now available.
      • Use the file browser in the LWJGL website to download the executables.
      • For example, the latest Windows x64 build of shaderc can be found under nightly/windows/x64/bgfx-tools/.
    • vma: VmaVulkanFunctions.set(VkInstance, VkDevice) will now use Vulkan 1.1 functions instead of KHR_get_memory_requirements2 functions, if available.
    • Generator: The template DSL has been simplified considerably.
    • Generator: Added the LWJGL Template Extraction Tool. It uses the new Clang bindings to parse native headers and extract LWJGL template declarations.
      • Extracts both declarations and associated documentation.
      • Written in Kotlin. The source can be found in the extract module.

    Fixes

    • Core: Fixed text decoding from buffer with .position() > 0.
      • Affected all decoders on Java 9+, only UTF-16 on Java 8.
    • Core: Fixed the bounds check in memCopy. (#414)
    • OpenAL: Fixed signature of alListener3i. (#427)
    • OpenVR: The pGamePoseArray parameter of VRCompositor_WaitGetPoses is now nullable. (#418)
    • OpenVR: Fixed returned type of VRRenderModels_GetComponentStateForDevicePath.
    • OpenVR: Renamed VRInput_UncompressSkeletalActionData to VRInput_DecompressSkeletalBoneData.
    • OpenVR: Fixed wrong modifiers in VRInput functions:
      • VRInput_GetDigitalActionData
      • VRInput_GetAnalogActionData
      • VRInput_GetPoseActionData
      • VRInput_GetSkeletalActionData
      • VRInput_GetOriginTrackedDeviceInfo
    • vma: The native library is now initialized automatically.
    • vma: Optional KHR_get_memory_requirements2 addresses in VmaVulkanFunctions are now nullable.
    • vma: Nullability of VmaAllocationCreateInfo & VmaAllocationInfo members.

    Breaking Changes

    (B): binary incompatible change
    (S): source incompatible change
    
    • Core: sun.misc.Unsafe is now required, there is no JNI fallback.
    • vma: The VmaVulkanFunctions.set helper method now returns VmaVulkanFunctions. (B)

    Known Issues

    • Core: LWJGL 3.2.1 is incompatible with Java 12 or higher. (#491)
      • This issue is fixed in LWJGL 3.2.3.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.2.1.zip(72.87 MB)
  • 3.2.0(Jul 30, 2018)

    Changes since 3.1.6:

    Bindings

    • Added Vulkan Memory Allocator bindings.
    • bgfx: Updated to API version 76 (up from 60)
      • bgfx_init now accepts a parameter structure instead of arguments.
    • glfw: Updated to pre-release 3.3.0 version (up from 3.3.0 pre-release):
      • Added support for gamepad mapping input modifiers (SDL 2.0.6+ format)
      • Added GLFW_FOCUS_ON_SHOW.
    • dyncall: Updated to revision 275 (up from 241)
    • jemalloc: Update to 5.1.0 (up from 5.0.1)
    • lz4: Updated to 1.8.2 (up from 1.8.1)
    • LibOVR: Updated to 1.26.0 (up from 1.20.0)
    • Nuklear: Updated to 4.00.1 (up from 3.00.2)
    • OpenGL: Introduced new GL11C...GL46C classes that include symbols of the Core Profile only.
      • Read the org.lwjgl.opengl package javadoc for more information on this feature.
    • OpenVR: Updated to 1.0.16 (up from 1.0.12)
    • rpmalloc: Updated to 1.3.1 (up from 1.2.2)
    • stb
      • Updated stb_image to 2.19 (up from 2.18)
      • Updated stb_image_write to 1.09 (up from 1.08)
      • Updated stb_truetype to 1.19 (up from 1.18)
      • Updated stb_vorbis to 1.14 (up from 1.13b)
    • tinyfiledialogs: Updated to 3.3.6 (up from 3.2.9)
    • Vulkan: Updated to 1.1.82 (up from 1.0.68)
      • Includes MoltenVK 1.0.16
    • xxhash: Update to 0.6.5 (up from 0.6.4)
    • Yoga: Updated to 1.9.0 (up from 1.7.1)
    • Zstd: Updated to 1.3.5 (up from 1.3.4)

    Improvements

    • Versioned classes in bindings now form inheritance hierarchies.
      • Applicable to the following versioned classes: AL, ALC, CL, EGL, GL, GLES, GLX, VK
      • For example, the GL30 class now extends the GL21 class, GL21 extends GL20 and so on.
      • With this change, importing a versioned class allows all symbols up to that version to be resolved. Earlier versions do not need to be imported separately.
    • perf(core): memGetAddress/memPutAddress are now an order of magnitude faster on 32-bit JVMs.
    • perf(core): Optimized pointer arithmetic by helping the JVM identify unsigned integers.
    • perf(core): The new java.util.Objects index check intrinsics are used on Java 9.
    • perf(core): MemoryUtil string decoding methods are now faster on both Java 8 and 9+.
      • The Java 9 implementations are tuned for compact strings (JEP 254).
    • perf(generator): Function pointers in capabilities classes are not sorted by name anymore.
      • This makes it more likely that for functions that are commonly used together, their respective pointers will be closer in memory, avoiding unnecessary cache misses.
    • Generator: org.lwjgl.system.JNI now includes signatures for known callback functions.
      • Can be used for callback function delegation.
    • Generator: Added support for custom methods in struct classes.
    • Generator: Added fluent setters for nested structs.
    • Generator: Made StructBuffer subclass generation optional.
    • Loader: Now prints the path of shared libraries loaded from system paths in debug mode, when possible.
    • docs(core): Improved PointerBuffer javadoc.
    • docs: The LWJGL javadoc is now generated with JDK 10.
    • Core: MemoryUtil methods now replace requests for zero-size allocations with non-zero-size allocations.
      • A zero-size allocation now always returns a non-NULL pointer or throws an OOME. This is consistent with ByteBuffer.allocateDirect and avoids the undefined behavior of native allocators.
      • The returned buffer has a capacity of zero, regardless of the actual allocation size.
    • Core MemoryUtil.memRealloc is not @Nullable anymore, will either succeed or throw an OOME, like memAlloc/memCalloc.
    • Core: It is now possible to create a MemoryStack backed by externally managed memory.
    • Core: The debug allocator now also tracks internal allocations of shared libraries that have been configured to use the LWJGL memory allocator.
      • This enables monitoring/debugging allocations inside shared libraries. Internal resources that are never released are now reported on shutdown.
      • Enabled by default when Configuration.DEBUG_MEMORY_ALLOCATOR is enabled.
      • May be disabled with Configuration.DEBUG_MEMORY_ALLOCATOR_INTERNAL.set(false).
    • LMDB: The LWJGL memory allocator is now used for internal allocations.
    • NanoVG/NanoSVG: The LWJGL memory allocator is now used for internal allocations.
    • OpenGL/GLES: Calling an unavailable function triggers a JNI FatalError instead of an arbitrary segfault.
      • Avoids the intimidating crash log and writes a clean stack trace to stderr.

    Fixes

    • Generator: Fixed nullability of macro bindings.
    • Generator: Fixed location of generated static blocks
    • Core: Struct buffer malloc/calloc methods now support zero capacity, instead of throwing a NPE.
    • macOS: Fixed version number detection in .dylib name mapping
    • Nullability fixes in:
      • Assimp
      • CGL
      • Yoga
      • Parameters of struct multi-setter methods
    • OpenCL: Fixed CL_DEVICE_PREFERRED_VECTOR_WIDTH_INT constant name.
    • OpenCL: Dropped unnecessary clSetKernalArg3<t> overloads.
    • OpenGL/GLES: The thread-local-free function pointer lookups do not depend on JVMTI anymore.
    • stb: Fixed type of stbi_write_jpg function's data parameter.

    Breaking Changes

    • Core: MemoryUtil.MemoryAllocationReport now also returns the address of the memory allocation.
    • NanoVG: Parameters windowWidth/windowHeight of the nvgBeginFrame function changed to float.

    Known Issues

    • vma: The native library is not initialized automatically.
      • Workaround: call Class.forName("org.lwjgl.util.vma.LibVma") before using the VMA bindings.
    • vma: KHR_get_memory_requirements2 function addresses in VmaVulkanFunctions are not optional.
      • Workaround: Enable the KHR_get_memory_requirements2 extension, or set the equivalent function addresses from Vulkan 1.1.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.2.0.zip(63.89 MB)
  • 3.1.6(Feb 4, 2018)

    Changes since 3.1.5:

    Bindings

    • bgfx: Updated to API version 60 (up from 55)
    • glfw: Updated to pre-release 3.3.0 version (up from 3.3.0 pre-release):
      • Support for lock key modifiers (GLFW_LOCK_KEY_MODS input mode, GLFW_MOD_CAPS_LOCK, GLFW_MOD_NUM_LOCK)
      • Support for string window hints (glfwWindowHintString, GLFW_COCOA_FRAME_NAME, GLFW_X11_CLASS_NAME, GLFW_X11_INSTANCE_NAME)
      • Support monitor & joystick user ponters (glfwSetMonitorUserPointer, glfwGetMonitorUserPointer, glfwSetJoystickUserPointer, glfwGetJoystickUserPointer)
      • Support for window content scale callbacks (glfwSetWindowContentScaleCallback)
      • Support for cursor hover tests (GLFW_HOVERED)
    • lz4: Update to 1.8.1 (up from 1.8.0)
    • Nuklear: Update to 3.00.2 (up from 2.00.4)
    • OpenVR: Updated to 1.0.12 (up from 1.0.10)
    • rpmalloc: Updated to 1.2.2 (up from 1.2.0)
    • stb
      • Updated stb_dxt to 1.08b (up from 1.0.7)
      • Updated stb_image to 2.18 (up from 2.16)
      • Updated stb_image_write to 1.08 (up from 1.07)
        • STBIW_ZLIB_COMPRESS can be overridden at runtime with stbi_zlib_compress.
      • Updated stb_truetype to 1.18 (up from 1.17)
      • Updated stb_vorbis to 1.13b (up from 1.11)
    • tinyfiledialogs: Updated to 3.2.9 (up from 3.2.4)
    • Vulkan: Updated to 1.0.68 (up from 1.0.65)
    • xxhash: Updated to 0.6.4 (up from 0.6.3)
    • Zstd: Updated to 1.3.4 (up from 1.3.2)
    • Yoga: Updated to 1.9.0 (up from 1.7.0)

    Improvements

    • Added JSR-305 nullability annotations to the core and all bindings. (#344)
      • Enables static analysis tools (FindBugs, IDEs) to detect accesses that could cause NullPointerException. Eliminating those improves the quality of LWJGL applications.
      • Enables better interopation with JVM-based languages that feature built-in null-safety. For example, see Kotlin's JSR-305 support.
    • Added Configuration setting to disable function lookup checks.
    • lmdb: Databases are now binary compatible across 32 & 64-bit architectures. (#364)
      • MDB_VL32 is enabled on 32-bit builds.
    • par_shapes: Patched to support 32-bit indices and extremely dense meshes.
    • stb_truetype: Exposed members of internal structures for advanced glyph packing customization. (#358)
    • Tootle: Now supports the Direct3D rasterizer for overdraw optimization.

    Fixes

    • JPMS: A natives module now requires transitive the corresponding Java module, instead of the opposite. (#334)
      • Enables loading shared libraries from non-modular paths/JARs.
    • JPMS: module-info files have been moved under META-INF/version/9/ (#334)
      • All LWJGL artifacts are now multi-release JAR files to avoid trouble with older tools that are not compatible with Java 9.
    • JPMS: Added appropriate requires static declarations to satisfy optional binding interop dependencies. (#369)
    • Fixed broken javadoc links in all bindings. Also updated URLs to avoid redirects.
    • bgfx: Restored default API thread encoder functions, that were erroneously removed in 3.1.4.
    • LibOVR: Fixed ovr_TraceMessage signature.
    • OpenAL: Fixed capability name of the AL_SOFT_source_resampler extension.
    • Tootle: Fixed pnClusterRemapOut parameter validation.

    Breaking Changes

    • Several methods that previously accepted null/NULL and returned null, now require non-null input.
      • Applies to: struct & callback creation methods and memByteBuffer/memUTF8/stack.UTF8/etc.
      • Added corresponding methods with the Safe suffix that accept null/NULL, matching the old behavior.
      • With this change the common case (non-null input) requires no code changes and is warning/error-free. The uncommon case (null input) is recognizable (the suffix) and must be handled properly to eliminate warnings/errors.
    • Allocation methods that returned null/NULL on allocation failure, now throw OutOfMemoryError instead. This matches the behavior of ByteBuffer.allocateDirect.
      • Applies to: struct allocation methods and memAlloc/memCalloc/etc.
      • Does not apply to allocations via direct binding calls (e.g. LibCStdlib.malloc).
    • Getters of struct members that should never be NULL, throw NullPointerException instead of returning null when the struct instance is not initialized.
      • Use Struct::isNull to test pointer members of untrusted struct instances.
    • bgfx: Restored native mapping of bgfx_init(_vendorId) and bgfx_update_texture_cube(_side) parameters. (#368)
    • bgfx: uint16_t bitfield constants are now mapped to int. (#368)
    • glfw: glfwInitHintString has been renamed to glfwWindowHintString.
    • lmdb: Databases developed on 32-bit architectures must be recreated. (#364)
    • par_shapes: Changed par_shapes_mesh::triangles from uint16_t/ShortBuffer to uint32_t/IntBuffer.
    • stb_rect_pack: stbrp_rect::was_packed is now mapped to Java boolean.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.1.6.zip(53.93 MB)
  • 3.1.5(Jan 23, 2018)

    Changes since 3.1.4:

    Bindings

    • Added AMD Tootle bindings.
      • Only the software rasterizer is supported.

    Fixes

    • Fixed various javadoc links.
    • par: Parsing of floating point values in L-systems is now locale-insensitive.
    • stb: Fixed buffer checks to account for row stride, when specified.
    • Generator: Fixed auto-size transformations by non-constant expressions.

    Breaking Changes

    • Removed array overloads from the LZ4 & ODBC bindings.
      • They were added by mistake in LWJGL 3.1.4.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.1.5.zip(52.83 MB)
  • 3.1.4(Nov 19, 2017)

    Changes since 3.1.3:

    Bindings

    • Added LZ4 bindings.
    • Added NanoSVG to the existing NanoVG bindings.
    • Added ODBC bindings.
    • Added Remotery bindings.
    • Added Zstandard bindings.
    • bgfx: Updated to API version 55 (up from 48)
    • glfw: Updated to pre-release 3.3.0 version (up from 3.3.0 pre-release):
      • Support for transparent window framebuffers (GLFW_TRANSPARENT_FRAMEBUFFER window hint)
      • Support for whole window opacity (glfwGetWindowOpacity and glfwSetWindowOpacity)
      • Support for content scale queries (glfwGetMonitorContentScale and glfwGetWindowContentScale)
      • Linux: Added support for the experimental Wayland backend. Enable with -Dorg.lwjgl.glfw.libname=glfw_wayland.
    • LibOVR: Updated to 1.20.0 (up from 1.18.0)
    • Nuklear: Updated to 2.00.4 (up from 2.00.2)
    • tinyfiledialogs: Updated to 3.2.4 (up from 3.0.5)
    • Vulkan: Updated to 1.0.65 (up from 1.0.61)
    • Yoga: Updated to 1.7.0 (up from 1.6.0)

    Improvements

    • Replaced Automatic-Module-Name with explicit JPMS modules.
      • Enables applications using LWJGL to be bundled in custom run-time images with the jlink tool.
    • lmdb: Significantly improved incremental growth performance on Windows.
      • Granularity of mapped memory commits increased from 4KB (page size) to 2MB.
      • This is an unofficial patch of ITS#8324.

    Fixes

    • EGL: Fixed nullability of eglMakeCurrent arguments.
    • OpenVR: Fixed mapping of Vulkan forward declarations.
    • Fixed native library resource discovery when running LWJGL as JPMS modules.
    • Fixed invalid size calculation in <StructType>.malloc(capacity) methods.
    • Fixed MemoryStack debugging when a try-with-resources block does not inline the call to AutoCloseable::close.
      • Supports Java 9 try-with-resources, which generates a synthetic $closeResource method.
      • Supports Kotlin's T.use, which uses the kotlin.AutoCloseable::closeFinally extension function.
    • Fixed build number lookup from the jar manifest.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.1.4.zip(52.17 MB)
  • 3.1.3(Sep 22, 2017)

    Changes since 3.1.2:

    Bindings

    • Added rpmalloc bindings.
      • Use -Dorg.lwjgl.system.allocator=rpmalloc to make it the default memory allocator.
    • Added new extensions to OpenCL, EGL, OpenGL and OpenGL ES.
    • Assimp: Updated to 4.0.1 (up from 3.3.1)
    • bgfx: Updated to API version 48 (up from 41)
    • EGL: Added support for latest extensions
    • glfw: Updated to pre-release 3.3.0 version (up from 3.3.0 pre-release):
      • Improvements to error code query (glfwGetError)
      • More library initialization hints (glfwInitHintString)
      • SDL_GameControllerDB support
        • Import gamepad mappings (glfwUpdateGamepadMappings)
        • Query to determine whether a joystick has a gamepad mapping (glfwJoystickIsGamepad)
        • Query the name of a controller provided by its gamepad mapping (glfwGetGamepadName)
        • Retrieve gamepad input state (glfwGetGamepadState, GLFW_GAMEPAD_*, GLFWgamepadstate)
        • Query the SDL compatible GUID of a joystick (glfwGetJoystickGUID)
      • Linux: Moved to evdev for joystick input
      • EGL: Fixed support for EGL_KHR_create_context_no_error
      • GLX: Added support for GLX_ARB_create_context_no_error
      • WGL: Added support for WGL_ARB_create_context_no_error and WGL_EXT_colorspace
    • jemalloc: Updated to 5.0.1 (up from 4.5.0)
    • LibOVR: Updated to 1.18.0 (up from 1.14.0)
    • lmdb: Updated to 0.9.21 (up from withdrawn 0.9.20)
    • NanoVG: Updated to latest version (performance updates and new nvgShapeAntiAlias function).
    • Nuklear: Updated to 2.00.2 (up from 1.37.0)
    • OpenAL: Added ALC_SOFT_output_limiter extension.
    • OpenAL Soft: Updated to 1.18.2 (up from 1.17.2)
    • OpenCL: Added support for OpenCL 2.2
    • OpenGL: Added support for OpenGL 4.6 and latest extensions
    • OpenGL ES: Added support for latest extensions
    • OpenVR: Update to 1.0.10 (up from 1.0.7)
    • stb
      • Updated stb_dxt to 1.07 (up from 1.06)
      • Updated stb_image to 2.16 (up from 2.15)
      • Updated stb_image_resize to 0.95 (up from 0.94)
      • Updated stb_image_write to 1.07 (up from 1.05)
      • Updated stb_truetype to 1.17 (up from 1.15)
      • Updated stb_vorbis to 1.11 (up from 1.10)
    • tinyfiledialogs: Updated to 3.0.5 (up from 2.8.3)
    • Vulkan: Updated to 1.0.61 (up from 1.0.49)
    • xxhash: Updated to 0.6.3 (up from 0.6.2)
    • Yoga: Updated to 1.6.0 (up from 1.5.0)

    Improvements

    • Generator: Added @NativeType annotations to generated bindings. Documents the native type of:
      • Callback and struct classes.
      • Struct members.
      • Function parameters and return values.
    • The default memory allocator on Windows is now the system allocator instead of jemalloc.
      • jemalloc is not properly optimized for Windows and its performance is not competitive.
      • jemalloc is still a major performance win on Linux and macOS.
      • rpmalloc is faster on all platforms but requires per-thread setup, so must be enabled manually.
    • Buffers created via MemoryUtil may now have up to Integer.MAX_VALUE elements, regardless of element size.
      • For example this allows a LongBuffer allocation of up to 16GB.
    • Added typed overloads to MemoryUtil::memSet and MemoryUtil::memCopy.
    • StructBuffer subclasses are now Iterable and have stream() and parallelStream() methods.
    • OpenGL: Added LongBuffer overloads to buffer object functions.

    Fixes

    • bgfx: Fixed signature of bgfx_create_frame_buffer_from_attachment.
    • OpenGL: Fixed signature of glPixelStoref.
    • OpenGL: ARB_direct_state_access interactions are now respected when checking if the extension is available.
    • stb_image: added ShortBuffer overload to stbi_image_free.
    • stb_truetype: Fixed signature of stbtt_PackFontRangesGatherRects and stbtt_PackFontRangesRenderIntoRects.

    Breaking Changes

    • glfw: Signature of glfwGetError has changed.
    • jemalloc: Removed JEmacros and moved its functionality to JEmalloc.
    • jemalloc: ChunkHooks has been replaced by ExtentHooks.
    • OpenCL: Removed two confusing clCompileProgram overloads.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.1.3.zip(48.15 MB)
  • 3.1.2(May 15, 2017)

    Changes since 3.1.1:

    Bindings

    • Added OpenVR bindings.
    • Added Tiny OpenEXR bindings.
    • Added Yoga bindings.
    • bgfx: Updated to API version 41 (up from 34)
    • glfw: Updated to pre-release 3.3.0 version (up from 3.2.1). Includes many fixes and new features:
      • Last error code query (glfwGetError)
      • Requesting attention from the user (glfwRequestWindowAttention)
      • Platform dependent scancodes for keys (glfwGetKeyScancode)
      • Window maximization events (glfwSetWindowMaximizeCallback)
      • Window attribute modification (glfwSetWindowAttrib)
      • Joystick hats (glfwGetJoystickHats)
      • Library initialization hints (glfwInitHint)
      • Headless OSMesa backend
      • Cursor centering control (GLFW_CENTER_CURSOR)
      • macOS: Cocoa hints (GLFW_COCOA_RETINA_FRAMEBUFFER, GLFW_COCOA_FRAME_AUTOSAVE, GLFW_COCOA_GRAPHICS_SWITCHING, GLFW_COCOA_CHDIR_RESOURCES, GLFW_COCOA_MENUBAR)
      • macOS: Vulkan support via MoltenVK
      • X11: Moved to XI2 XI_RawMotion for disabled cursor mode motion input
      • EGL: Added support for EGL_KHR_get_all_proc_addresses and EGL_KHR_context_flush_control
    • jemalloc: Updated to 4.5.0 (up from 4.4.0)
    • LibOVR: Update to 1.14.0 (up from 1.10.0)
    • lmdb: Updated to 0.9.20 (up from 0.9.18)
    • NanoVG: Added support for fallback fonts.
    • nuklear: Updated to 1.37.0 (up from 1.29.1, with the new versioning)
    • OpenAL: Added AL_SOFT_source_resampler extension.
    • stb
      • Updated stb_dxt to 1.0.6 (up from 1.0.4)
      • Updated stb_easy_font to 1.0 (up from 0.7)
      • Updated stb_image to 2.15 (up from 2.13)
      • Updated stb_image_resize to 0.94 (up from 0.91)
      • Updated stb_image_write to 1.05 (up from 1.02)
      • Updated stb_perlin to 0.3 (up from 0.2)
      • Updated stb_rect_pack to 0.11 (up from 0.10)
      • Updated stb_truetype to 1.15 (up from 1.12)
      • Updated stb_vorbis to 1.10 (up from 1.09)
    • tinyfiledialogs: Updated to 2.8.3 (up from 2.7.2)
    • Vulkan: Updated to 1.0.49 (up from 1.0.38)

    Improvements

    • MemoryStack: Increased default stack size to 64kb (up from 32kb)
    • Shared library loading can now utilize a ClassLoader specified by the caller. (#277)
    • Significantly reduced DEBUG_MEMORY_ALLOCATOR and DEBUG_STACK overhead in Java 9 using the new StackWalker API.
    • Migrated windows builds to appveyor and updated to Visual Studio 2017 (up from 2015)
    • EGL: The core API now includes javadoc links to the Khronos references pages
    • OpenGL ES: The core API now includes javadoc links to the Khronos references pages

    Fixes

    • Assimp: Struct member nullability fixes
    • Linux: Removed dependencies to newer GLIBC versions.
    • LibOVR: Fixed layout of the ovrInputState struct.
    • OpenAL: Removed buffer auto-sizing from alcCaptureSamples. The number of samples must now be specified explicitly, similar to alcRenderSamplesSOFT.
    • Vulkan: Function addresses are now retrieved only once, using the optimal method for each function type.
      • This avoids warnings on pedantic validation layers.
    • Fixed callback invocation bugs on 32-bit architectures.
    • Fixed various javadoc formatting issues (#308)

    Breaking Changes

    • Mapped more integer parameters and return values to Java boolean, that were missed while working on #181.
      • Xlib's Bool
      • OpenCL's cl_bool
      • DynCall's DCbool
    • Moved JNI global reference functions from MemoryUtil to the generated org.lwjgl.system.jni.JNINativeInterface.
    • The Vulkan capabilities have been split into two classes: VKCapabilitiesInstance and VKCapabilitiesDevice.
      • Flags for core Vulkan versions exist in both classes.
      • Flags for instance extensions exist only in VKCapabilitiesInstance.
      • Flags for device extensions exist only in VKCapabilitiesDevice.
      • Functions that dispatch on VkInstance or VkPhysicalDevice exist only in VKCapabilitiesInstance.
      • Functions that dispatch on VkDevice and device-derived handles exist only in VKCapabilitiesDevice.
      • Bootstrapping functions can be retrieved with VK.getFunctionProvider().
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.1.2.zip(44.91 MB)
  • 3.1.1(Dec 27, 2016)

    Changes since 3.1.0:

    Bindings

    • Added Assimp bindings.
    • bgfx: Updated to API version 34 (up from 28)
    • jemalloc: Updated to version 4.4.0 (up from 4.2.1)
    • LibOVR: Updated to version 1.10.0 (up from 1.9.0)
    • nuklear: Updated to version 1.191 (up from 1.17)
    • Vulkan: Updated to version 1.0.38 (up from 1.0.32)
    • stb: Updated stb_image to 2.13 (up from 2.12)
    • tinyfiledialogs: Updated to version 2.7.2 (up from 2.6.1)

    Improvements

    • Refactored function pointer lookups in OpenAL, OpenGL and OpenGL ES.
      • Significant reduction in bytecode size (and corresponding JIT code).
      • No thread-local lookup in GL and GLES, even with incompatible contexts.
      • Removed obsolete thread-local and capabilities state Configuration options.
    • Linux: All natives are now built with GCC 6.2 (up from 4.8)
    • Loader: If jemalloc initialization fails and org.lwjgl.system.allocator has not been set, a simple warning is now shown instead of an exception.
    • Structs: Added bound checks to element accessors of array members.
    • Generator: Validation is now required for all data pointer parameters. If validation is not possible, such parameters must be marked as potentially unsafe.
    • The SHA-1 hash of shared libraries is now included in the corresponding natives JAR files.
    • The upstream git revision used to build shared libraries is now included in the corresponding natives JAR files.

    Fixes

    • Fixed loader diagnostics when System.loadLibrary fails.
    • Fixed setters of struct members with optional AutoSize. (#255)
    • Fixed MemoryUtil.memRealloc to return null when the allocation fails.
    • Vulkan: Function pointer loading of disabled extensions is now skipped.
    • Generator: binding.DISABLE_CHECKS is now respected in structs.

    Breaking Changes

    • macOS: LWJGL now requires macOS 10.9/Mavericks or later (up from 10.7/Lion)
    • A small number of method signatures have changed because of auto-size transformations that were missing in previous releases.
    • NanoVG: Text functions with an end pointer to the end of the string are now auto-size transformed. Buffers passed to them should not include a null-terminating byte.
    • Added LibC prefix to all class names in the libc bindings, to avoid conflicts with standard Java classes (Locale, String, etc.)
    • OpenGL and OpenGL ES now come with native libraries (lwjgl_opengl and lwjgl_opengles respectively).
    • Removed MemoryUtil.memSetupBuffer.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.1.1.zip(38.70 MB)
  • 3.1.0(Oct 30, 2016)

    Changes since 3.0.0:

    Bindings

    • Bindings have been split into modules and are available as separate artifacts. (#100)
      • The download configurator on the website can be used to customize LWJGL builds and Maven/Gradle projects.
    • Added LMDB bindings.
    • Added Nuklear bindings. (#101)
    • Added Tiny File Dialogs bindings.
    • Added bgfx bindings. (#240)
    • Added support for new EGL, OpenCL, OpenGL, OpenGL ES and Vulkan extensions.
    • Updated all bindings to latest versions.
    • Vulkan javadoc is now almost identical to the Vulkan man pages, with links to the online Vulkan specification.

    Improvements

    • Generator: Removed buffer object binding checks. (#197)
    • Generator: Added support for mapping byte/short parameters to int.
    • Generator: Added support for va_list parameters.
    • Generator: Reduced bytecode size of generated methods.
    • Generator: The Vulkan bindings are now automatically generated.
    • Optimized strlen methods used internally by LWJGL.
    • Optimized misaligned memSet and memCopy.
    • Added support for stack allocations with custom alignment.
    • Removed allocation functionality from read-only, externally managed structs.
    • Improved library loading diagnostics and added Configuration.DEBUG_LOADER option.
    • Libraries extracted by the SharedLibraryLoader are now locked to avoid conflicts with other processes (e.g. antivirus software). (#225)
    • Simplified javadoc of unsafe versions.

    Fixes

    • Callback instances are now tracked when the DEBUG_MEMORY_ALLOCATOR option is enabled.
    • Fixed realloc tracking in the debug allocator.
    • Shared libraries that ship with LWJGL are now always preferred over system libraries.
    • Fixed return type of functions that return pointer to boolean.
    • stb_image: Fixed result auto-sizing of stbi_load* functions.
    • Functions that deallocate memory no longer have Java array overloads.
    • Fixed memSet bugs.
    • Fixed Java array overload generation for functions with multiple auto-size-result parameters.
    • Fixed custom checks in Java array overloads.
    • Fixed lookup of Critical JNI natives on Windows x86.
    • Disabled Critical JNI natives for functions affected by JDK-8167409 on Linux & MacOS.

    Breaking Changes

    • xxHash: Added support for stack allocation of streaming hash state. Opaque handles have been replaced by the XXH*State structs.
    • NanoVG: Dropped version suffixes from NanoVGGL classes.
    • Mapped more integer parameters and return values to Java booleans, that were missed while working on #181.
    • Dropped VKUtil class and moved the version macros to VK10.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.1.0.zip(28.49 MB)
  • 3.0.0(Jun 3, 2016)

    Changes since 3.0.0b:

    BINDINGS

    • Added support for Java array parameters and HotSpot Critical Natives. (#175)
    • Added Vulkanl bindings. (#50)
    • Added NanoVG bindings. (#99)
    • Added NativeFileDialog bindings.
    • Added par_shapes.h bindings.
    • Added dyncall bindings.
    • Added jawt bindings for AWT/Swing integration. (#125)
    • Added simple OS-specific window creation bindings, for custom window/context creation. (#105)
    • Added missing OpenCL and OpenAL extensions.
    • Fully documented OpenCL and OpenAL.
    • Moved WGL and GLX capabilities to the new WGLCapabilities and GLXCapabilities classes, respectively. Functionality in WGL, GLX and corresponding extensions that does not require a current context can now be used without creating a dummy context first. (#171)

    IMPROVEMENTS

    • Added stack allocation APIs (the MemoryStack class and new allocation methods in struct classes and MemoryUtil).
    • Made the implementations of PointerBuffer and Struct/StructBuffer subclasses as lightweight as possible. This makes it easier for escape analysis to eliminate allocations.
    • Minor struct API improvements.
    • Added nullability information to struct members, to protect against buggy code crashing the JVM.
    • All bindings are updated to the latest versions of the corresponding libraries. Notably, GLFW now has glfwSetWindowIcon and glfwSetWindowMonitor, it now doesn't lack anything compared to LWJGL 2's Display.
    • Refactored callbacks for Java 8. (#182)
    • Added NativeResource interface and made freeable objects usable as resources in try-with-resources statements. (#186)
    • Faster thread-local lookups for the stack and current capabilities. New options in Configuration can be used to complete eliminate thread-local lookup in OpenGL, OpenGL ES and OpenAL, when it is known that only a single context will be used, or that all contexts will be compatible (same capabilities and same function pointers).
    • Added memSlice for all buffers types in MemoryUtil. (#179)
    • Refactored the Configuration class for type safety and added more options.
    • JDK 9 can now be used to build and run LWJGL.
    • Javadoc is now generated with JDK 9. The API is fully indexed and search functionality is available. Also made multiple Javadoc formatting improvements.
    • Improved debug diagnostics on startup and when loading the LWJGL shared library fails.
    • Optimized memSet and memCopy for small buffers.

    FIXES

    • Stopped using UPX compression for binaries. This eliminates various integration issues and virus scanning false-positives.
    • The SharedLibraryLoader now works with any shared library, not only libraries LWJGL knows about. (#176)

    BREAKING CHANGES

    • LWJGL now requires Java 8 to build and run. Certain custom interfaces have been replaced with java.util.function interfaces. (#177)
    • Dropped support for Linux x86. (#162)
    • Dropped libffi bindings.
    • Dropped ALDevice/ALContext wrappers from OpenAL and CLPlatform/CLDevice wrappers from OpenCL. (#152)
    • Dropped the getInstance() method from bindings loaded from shared libraries. Function pointers are now stored either in capabilities classes or in a nested Functions inner class.
    • Dropped infrequently used method overloads in bindings. Full javadoc is now generated on (almost) all overloads.
    • Dropped utility classes that were not useful.
    • Added AutoSize support to struct members. Instance setters for the corresponding count/size members were removed to avoid bugs and confusion.
    • Replaced MemoryUtil.memFree(StructBuffer) with StructBuffer.free().
    • Renamed __ALIGNMENT to ALIGNOF in struct classes.
    • Removed org.lwjgl.system.Retainable interface. Closure and FunctionProvider subclasses are now destroyed using .free() instead of .release().
    • Moved xxHash and SSE bindings to the org.lwjgl.util package.
    • Integer-boolean native types (0 or 1 are the only legal values) are now mapped to Java booleans. (#181)
    • Macros without parameters are now generated as static final values, not methods.
    Source code(tar.gz)
    Source code(zip)
    lwjgl.zip(16.50 MB)
  • 3.0.0b(Nov 21, 2015)

    This build includes the following changes:

    • 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.
    Source code(tar.gz)
    Source code(zip)
    lwjgl-3.0.0b.zip(11.70 MB)
  • 3.0.0a(Nov 21, 2015)

Owner
Lightweight Java Game Library
LWJGL is a Java library that enables cross-platform access to graphics, audio and parallel computing APIs.
Lightweight Java Game Library
A legacy-fabric mod that makes minecraft versions older than 1.13 run using LWJGL 3 instead of the legacy LWJGL 2

A legacy-fabric mod that makes minecraft versions older than 1.13 run using LWJGL 3 instead of the legacy LWJGL 2

Zarzel K. Shih 17 Dec 4, 2022
Small mod for Minecraft Forge 1.16.5 that sends messages of in-game events to a channel in your Discord server. This mod also enables cross-chatting between Minecraft and Discord.

DiscordSync Small mod for Minecraft Forge 1.16.5 that sends messages of in-game events to a channel in your Discord server. This mod also enables cros

AeonLucid 4 Dec 20, 2022
Mesh is a cross-version minecraft mod development platform for Forge and Fabric.

Mesh is a cross-version minecraft mod development platform for Forge and Fabric. Supported Versions Mesh will eventually be able to run on most f

null 12 Dec 13, 2022
Cross-platform Java game development framework.

Features Kronos is a open source, cross-platform game development library with a robust ecosystem. Listed below are current and planned (*) features:

Temps 0 Dec 19, 2022
A high-level cross-platform 2D game development API

mini2Dx A high-level game development API for LibGDX inspired by Slick Website Wiki Community Javadoc Downloads Goals The main objective of mini2Dx is

null 492 Dec 24, 2022
Blaze4D - Minecraft but with Vulkan using the Rosella engine.

Information Blaze4D is a Fabric mod that changes Minecraft's rendering engine to use the Vulkan Graphics Library, it is currently in Early Development

Kiln Graphics 257 Dec 30, 2022
An arcade game project which made using java and swing for graphics

Arcade_Game_Development This is an arcade game project which made using java and swing for graphics. Meteor Dodge Here you have to dodge the meteor an

Md. Shakib Shahariar Junayed 1 May 25, 2022
[LEGACY] LWJGL 2.X - The Lightweight Java Game Library.

[LEGACY] LWJGL - Lightweight Java Game Library WARNING This is the repository of the original LWJGL, which is no longer actively maintained. Unless yo

Lightweight Java Game Library 529 Dec 26, 2022
A Java Game Engine created in Java with LWJGL!

?? Suffler Engine Suffler Game Engine is an engine created in java using OpenGL to Graphics. Currently being developed at Eclipse, and Visual Studio C

Suffler Engine 2 Jul 23, 2022
:wrench: LibGDX/LWJGL tutorials and examples

lwjgl-basics is a minimal shader-based library for 2D LWJGL sprite games. It provides essential utilities for handling textures, shaders, and sprite r

Matt DesLauriers 1.8k Jan 3, 2023
using LWJGL to make a mini minecraft (mac also can run)

MineCraft Mini Features MineCraft Lite in Java and OpenGL Physics simulation, water simulation Perlin noise algorithm to generate maps Directional flo

null 1 Jan 4, 2022
contents based on article cross-team collaboration

camelk-team-collaboration This repository contains all the sources showcased in the following Red Hat Developers article: https://developers.redhat.co

null 7 Apr 27, 2022
The loader for mods under Fabric. It provides mod loading facilities and useful abstractions for other mods to use, which is compatible with spigot now

Silk The loader for mods under Fabric. It provides mod loading facilities and useful abstractions for other mods to use, which is compatible with spig

null 1 Oct 1, 2022
A Minecraft (Fabric) mod that improves the statistics screen and makes it more useful.

Better Statistics Screen This Minecraft mod replaces the Vanilla statistics screen with an new and improved statistics screen that is easier to use an

TheCSDev 7 Dec 31, 2022
Apron: Classic Modding APIs on Babric

Apron Apron adds a compatibility layer between Fabric and several legacy modding APIs. In essence, it is a complete reimplementation of the API mods o

Better Than Updates 9 Dec 4, 2022
A 1.7.10 Forge Mod to allow players to access easy stats like latency, FPS, and CPS

EZStats A 1.7.10 Forge Mod to allow players to access easy stats like latency, FPS, and CPS. Currently a work in progress, all code is accessable in t

applesfruit 4 Aug 8, 2022
A Minecraft mod on the Fabric modloader which aims to add some useful vehicles.

Automobility A Minecraft vehicle mod adding customizable cars. Made for ModFest 1.17 Screenshots Try it out! Recommended to use along with LambdaContr

null 31 Dec 15, 2022
Spigot plugin with a bunch of quite useful commands in it!

QuiteUsefulCommands Spigot plugin with a bunch of quite useful commands in it. Install Download the latest release and drag it into your server's plug

MightyCoderX 6 Aug 20, 2022
Adds backpack that can be access from inventory.

Inventory Backpack Mod <-- Video About This mod adds backpacks that can be accessed from inventory. Origins It's based on forge mod Quark Oddities, or

Jakub Trzeciak 4 Jul 16, 2022