lwjgl / lwjgl3-www

The LWJGL 3 website.

[LEGACY] LWJGL - Lightweight Java Game Library

WARNING

This is the repository of the original LWJGL, which is no longer actively maintained. Unless you have released a product that uses LWJGL 2.x, you should probably be looking at LWJGL 3.

The Lightweight Java Game Library (LWJGL) is a solution aimed directly at professional and amateur Java programmers alike to enable commercial quality games to be written in Java. LWJGL provides developers access to high performance crossplatform libraries such as OpenGL (Open Graphics Library), OpenCL (Open Computing Language) and OpenAL (Open Audio Library) allowing for state of the art 3D games and 3D sound. Additionally LWJGL provides access to controllers such as Gamepads, Steering wheel and Joysticks. All in a simple and straight forward API.

Website: http://legacy.lwjgl.org Forum: http://forum.lwjgl.org Bugs/Suggestions: https://github.com/LWJGL/lwjgl/issues

Compilation

LWJGL requires a JDK and Ant installed to compile, as well as your platforms native compiler to compile the JNI.

• ant generate-all
• ant compile
• ant compile_native

lwjgl3-www's Issues

Download link outside <BuildConfigurator />

Some people just want everything. Provide a link outside to download the entire ZIP bundle.

Use GitHub's release link to save bandwidth costs.

Customize Page Includes Broken Link to Intel SSE

The customize page (when showing descriptions) links to https://software.intel.com/en-us/node/523328, which redirects to the developer homepage. This page might be the new one to link to.

Provide an option to generate a complete pom.xml/build.gradle

Every once in a while, people are tripped over by the fact that the customizer https://www.lwjgl.org/customize (when in Maven or Gradle mode) does not generate a complete script that would work out of the box. Those generated scripts are rather meant to be pasted into an existing skeleton pom.xml/build.gradle file.

However, people new to both LWJGL and Maven/Gradle who simply want to try things out, would probably prefer a complete/working pom.xml/build.gradle file.

This issue is related to: LWJGL/lwjgl3-wiki#7

OpenVR bindings for Windows x86

When I tried to generate a build.gradle for file using OpenVR bindings on Windows x86 with the build configurator (https://www.lwjgl.org/customize), the OpenVR checkbox got disabled when I selected the Windows x86 natives (see the screenshot I made).

But why is that? It seems that such natives for Windows x86 are just available when I manually add it to the build.gradle and build it (the natives are just in the produced jar when I open it with an archive manager).

Questionable customized Gradle build script with Windows

In the customize page with Gradle mode and both Windows x64 and Windows arm64 natives selected, we get:

switch (OperatingSystem.current()) {
	case OperatingSystem.WINDOWS:
		def osArch = System.getProperty("os.arch")
		project.ext.lwjglNatives = osArch.contains("64")
			? "natives-windows${osArch.startsWith("aarch64") ? "-arm64" : ""}"
			: "natives-windows-x86"
		break
}

Why the last branch contains "natives-windows-x86"? Shouldn't it be just "natives-windows"?

Cannot render html in production mode?

in my case, react can't render html in production mode, im run npm run start-production

The website is stuck in "LOADING..." state on Firefox

Firefox version: 94.0.2 (32-bit)
Host OS: Windows 10
Link: https://www.lwjgl.org/
Screenshot:

Works fine in chromium though

OpenXR is listed under releases

OpenXR was only recently added to LWJGL, but it's only supported in the snapshots.

Add SBT mode to build customizer

See LWJGL/lwjgl3#395.

Prompt to update service worker

Service worker updating behavior is not appropriate for a project like LWJGL. Library users usually visit the site whenever a new update comes out. Therefore it is highly likely that on their repeat visit an old version of the site will still be active (SW only updates the site after the last tab closes or with a hard-refresh).

We need to prompt the user to force installation of the new SW version and update the page immediately.

Replace the dyncall 'feature' text

When 3.2.3 arrives, it deprecates dyncall in favor of libffi. A simple text replacement would do. Putting this here so it's not forgotten.

Customization & Utilities
Use dyncall to call functions from any native library, use jemalloc for efficient and tunable memory management, use the stb collection of libraries for texture loading, font rendering and much more.

Add new release detection to localStorage config loading

When the previously used configuration is restored from Window.localStorage the user should be notified if a new version has been released.

"Failed to fetch" when downloading as ZIP

To replicate, select any combination of platform natives in 3.3.0, and select OpenAL to put in.

lwjgl.org displays "Loading..." on Safari

The page currently looks like this:

The problem seems to be the compiled javascript code:

I'm currently using Safari 13.0.5 on MacOS Mojave:

I have already deleted cache, and tried lading the page on incognito mode for better measure

build.gradle.kts generation creates a script that puts natives-linux on the windows classpath

When you generate a kts gradle build file the lwjglNatives script gives windows people linux binaries.

lwjgl3-www/client/routes/customize/lib/gradle.ts

Line 124 in f31f875

\t\t\t"natives-linux\${if (it.startsWith("aarch64")) "-arm64" else ""}"

val lwjglNatives = when (OperatingSystem.current()) {
	OperatingSystem.LINUX   -> System.getProperty("os.arch").let {
		if (it.startsWith("arm") || it.startsWith("aarch64"))
			"natives-linux-${if (it.contains("64") || it.startsWith("armv8")) "arm64" else "arm32"}"
		else
			"natives-linux"
	}
	OperatingSystem.MAC_OS  -> "natives-macos"
	OperatingSystem.WINDOWS -> System.getProperty("os.arch").let {
		if (it.contains("64"))
			"natives-linux${if (it.startsWith("aarch64")) "-arm64" else ""}"
		else
			"natives-linux-x86"
	}
	else -> throw Error("Unrecognized or unsupported Operating system. Please set \"lwjglNatives\" manually")
}

Include natives for all platforms in generated build files

When using the build configurator to create a gradle build file with only the core of LWJGL, it will generate the following file:

import org.gradle.internal.os.OperatingSystem

project.ext.lwjglVersion = "3.2.3"

switch (OperatingSystem.current()) {
	case OperatingSystem.LINUX:
		def osArch = System.getProperty("os.arch")
		project.ext.lwjglNatives = osArch.startsWith("arm") || osArch.startsWith("aarch64")
			? "natives-linux-${osArch.contains("64") || osArch.startsWith("armv8") ? "arm64" : "arm32"}"
			: "natives-linux"
		break
	case OperatingSystem.MAC_OS:
		project.ext.lwjglNatives = "natives-macos"
		break
	case OperatingSystem.WINDOWS:
		project.ext.lwjglNatives = System.getProperty("os.arch").contains("64") ? "natives-windows" : "natives-windows-x86"
		break
}

repositories {
	mavenCentral()
}

dependencies {
	implementation platform("org.lwjgl:lwjgl-bom:$lwjglVersion")

	implementation "org.lwjgl:lwjgl"
	runtimeOnly "org.lwjgl:lwjgl::$lwjglNatives"
}

This uses a big switch statement to pick the natives for the current operating system. This is nice for development runs, but horrible when distributing with something like shadowJar: it will generate a fat jar file containing only the natives of the operating system that built it. This would cause the jar to work very well on the machine of the developer, but fail on any machine with a different operating system or architecture due to missing natives. If the developer doesn't open it up with an archive manager or tests on a different machine, he wouldn't even find out.

I would instead generate a file like this:

project.ext.lwjglVersion = "3.2.3"

repositories {
	mavenCentral()
}

dependencies {
	implementation platform("org.lwjgl:lwjgl-bom:$lwjglVersion")

	implementation "org.lwjgl:lwjgl"
	runtimeOnly "org.lwjgl:lwjgl::natives-windows"
	runtimeOnly "org.lwjgl:lwjgl::natives-windows-x86"
	runtimeOnly "org.lwjgl:lwjgl::natives-linux"
	runtimeOnly "org.lwjgl:lwjgl::natives-linux-arm32"
	runtimeOnly "org.lwjgl:lwjgl::natives-linux-arm64"
	runtimeOnly "org.lwjgl:lwjgl::natives-macos"
}

With this file, the natives for all operating systems will always be included, regardless on which operating system it is built. If shadowJar would be used on such a build file, the produced jar file will contain all natives and therefor work on all supported platforms. I would consider this more the Java way to do things.

This example was just for gradle, but similar arguments should hold for the other supported build systems as well. Note: If there is a better than way than shadowJar to distribute lwjgl applications, please let me know!

Remember previously selected configuration

should store previous selection and restore automatically on subsequent visits.

We could use localStorage to save selection as JSON. However, because localStorage is synchronous (has to flush to the disk), it may add unnecessary UI lag. Investigate alternatives.

Render bindings in groups

Group based on https://github.com/LWJGL/lwjgl3/blob/master/README.md

Option to include a copy of the JSON configuration file in the download

Download customize form unexpected behaviour

Browser: Firefox Quantum (64-bit) 58.0.1

To reproduce:
On website, go 'download' page > 'customize LWJGL 3' > Enable 'Gradle' > Enable 'Custom'. Add any of the libraries/frameworks.

Expected Behavior:
The library/framework checkbox should be highlighted

Actual Behavior:
The checkbox does not highlight. The preset jumps from 'custom' to 'getting started' (Or whatever it was set at before 'custom').

Here is a GIF showing the problem.

Build Customizer does not default to arm64 in Apple Silicon

Add release note links to the build configurator

Generated POM does not conform to the POM Code Convention

The POM generated from the /download page does not output a POM that follows the POMCC.
A simple fix is to move the <profiles> to the end of the POM.

ZIP generation is broken

Uncaught (in promise) TypeError: Object(...) is not a function
    at n.<anonymous> (route-customize.e765c99cd71304b187eb8f910ff31fc3.js:1)

Please pack the latest LICENSE from JOML

When downloading JOML 1.9.1 (or now 1.9.2), the downloaded zip file still contains JOML's old LICENSE file with the 2015-2016 copyright year.

Possibly incompatible Gradle script: No signature of method

Copying the Gradle code provided on the customize page I get the following error:

No signature of method: static org.gradle.nativeplatform.platform.OperatingSystem.current() is applicable for argument types: () values: []

As the error states, this happens in the first line of the switch statement generating the name of the native files.

My environment:

• Java 17.0.2 (from Adoptium.net)
• Gradle 7.3.3
• IntelliJ IDEA Ultimate 2021.1.1

What If I enable mangling process?

Do you know what causes the following error when I enable mangling? Won't it be possible to accomplish mangling with a specific options? I'm asking because after your webpack and process-manifest.js updates, my total bundle size increased by 30Kb (gzipped).

https://github.com/LWJGL/lwjgl3-www/blob/master/scripts/process-manifest.js#L121-L133

Additinal Question: Should I open another issue about that I can't see the exact location of the errors even if I define devtool prop in webpack config (sourcemap)? I'm also trying to figure out that case. I may send pr If I can.

Mention "-XstartOnFirstThread" requirement for macOS in "Get Started"

On macOS the JVM must be started with the -XstartOnFirstThread argument for GLFW to work. This is necessary because most GLFW functions must be called on the main thread and the Cocoa API on macOS requires that thread to be the first thread in the process. For this reason, on-screen GLFW windows and the GLFW event loop are incompatible with other window toolkits (such as AWT/Swing or JavaFX) on macOS. Off-screen GLFW windows can be used with other window toolkits, but only if the window toolkit is initialized before GLFW.

https://javadoc.lwjgl.org/org/lwjgl/glfw/package-summary.html

Issues in which the -XstartOnFirstThread flag is missing and consequently the JVM crashing are commonly raised in the forum, StackOverflow and on GitHub. While the requirement is documented in many places, the "Get Started" section on the website does not mention the flag at all. In my opinion, it is reasonable to expect users to read a bit of documentation but I doubt that added visibility could inflict any harm.

It is also worth noting that there are some existing checks for this in LWJGL. (See EventLoop.) However, as recent reports have shown they are somewhat unreliable and may break on some macOS versions, leaving the user clueless. [lwjgl3#538]

Site doesn't load on Edge

Add 'Unsupported Platforms' note to some bindings

As LWJGL begins to support macOS ARM64 and Windows ARM64 (and potentially more in the future), listing supported platforms for a binding can be unhelpful. It becomes too long if it supports most platforms. Making a note of unsupported platforms would make it easier to read.

Eg. bgfx:

becomes

Eg. Meow hash:

becomes

Shorter lists of supported platforms would remain:

Artifact download location should be customizable

For example download JOML & other addons directly from Maven:

https://repo.maven.apache.org/maven2/org/joml/joml/1.9.15/

Generator dependency issue with gradle

Using the generator from https://www.lwjgl.org/download to create a build.gradle file i get this configuration:

import org.gradle.internal.os.OperatingSystem

switch ( OperatingSystem.current() ) {
	case OperatingSystem.WINDOWS:
		project.ext.lwjglNatives = "natives-windows"
		break
	case OperatingSystem.LINUX:
		project.ext.lwjglNatives = "natives-linux"
	break
	case OperatingSystem.MAC_OS:
		project.ext.lwjglNatives = "natives-macos"
		break
}

project.ext.lwjglVersion = "3.1.2"

repositories {
	mavenCentral()
}

dependencies {
	compile "org.lwjgl:lwjgl:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-assimp:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-bgfx:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-egl:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-glfw:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-jawt:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-jemalloc:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-lmdb:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-nanovg:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-nfd:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-nuklear:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-openal:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-opencl:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-opengl:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-opengles:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-openvr:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-ovr:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-par:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-sse:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-stb:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-tinyexr:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-tinyfd:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-vulkan:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-xxhash:${lwjglVersion}"
	compile "org.lwjgl:lwjgl-yoga:${lwjglVersion}"
	runtime "org.lwjgl:lwjgl:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-assimp:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-bgfx:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-glfw:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-jemalloc:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-lmdb:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-nanovg:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-nfd:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-nuklear:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-openal:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-opengl:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-opengles:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-openvr:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-ovr:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-par:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-sse:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-stb:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-tinyexr:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-tinyfd:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-xxhash:${lwjglVersion}:${lwjglNatives}"
	runtime "org.lwjgl:lwjgl-yoga:${lwjglVersion}:${lwjglNatives}"
}

running gradle build I get the following error:

Could not resolve all files for configuration ':runtimeClasspath'.
> Could not find lwjgl-ovr-natives-linux.jar (org.lwjgl:lwjgl-ovr:3.1.2).
  Searched in the following locations:
      https://repo1.maven.org/maven2/org/lwjgl/lwjgl-ovr/3.1.2/lwjgl-ovr-3.1.2-natives-linux.jar

I can make the build successful changing runtime "org.lwjgl:lwjgl-ovr:${lwjglVersion}:${lwjglNatives}" to runtime "org.lwjgl:lwjgl-ovr:${lwjglVersion}".
Is this the correct dependency?

Ability to Import/Export selection in <BuildConfigurator />

• Export saves selection as JSON.
• Import validates & restores selection from a user-provided JSON file.

How do we initiate import before selecting the build? We may need a button outside the container.

javascript error in the customize page

hi,
there is an error about parsing json

Option to download a single merged JAR file instead of ZIP file with many JARs

• Investigate using JSZIP to read the dir/file structure of each downloaded jar and extract the contents
• Merge dir/file structure to a single tree
• Merge should ignore META-INF folders
  • Other potential conflicts?
• ZIP the final bundle and download as .jar
• Potential output:
  • A single JAR file with everything
  • A ZIP file with two JAR files inside it. One for classes and one for natives
  • A ZIP file with a JAR for classes and one JAR per platform for natives