Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (697)
Games in Android Showcase (202)
games submitted by our members
Games in WIP (767)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1] 2 3 ... 35
1  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-27 12:12:59
Reckon the way to do this is to just forget the business about passing the context, set all "images" in main thread?

Doing everything on the main thread is a legitimate solution. Reasons for using secondary thread(s) include: a) decoupling the event loop from rendering and b) decoupling loading OpenGL assets from rendering (asynchronous loading of models, textures etc).

For the specific issue you're having with the window not responding, I would recommend simplifying your code and posting a sample that reproduces the freeze.
2  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-27 07:42:45
Setting java.library.path or org.lwjgl.librarypath is not required. These two settings are still supported and used internally, but you shouldn't need them unless you're doing some customization (e.g. creating a platform-specific installer for your application).

LWJGL has something called the SharedLibraryLoader which takes care of extracting the native libraries from the natives JARs and loading them automatically. The only thing you need to do is add the JARs to the classpath. So, if for example you're making a GLFW+OpenGL application and are running on Windows, you'll have to set the classpath to include:


That's it. From the command line it's simple; if you have all LWJGL JARs in a subfolder called "lwjgl", you can do:

java -cp lwjgl/*;<other stuff here> my.application.Main

and it should just work. In Eclipse, or any other IDE, configure your project to include all the LWJGL JARs in the classpath.
3  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-26 18:02:39
LWJGL 3.1.0 is modular, meaning that each binding is now a separate artifact. The build configurator on the site can be used to include only the bindings you're going to use.

Setting up your project in Eclipse should be as simple as adding the JARs you downloaded to the project classpath.
4  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-26 14:29:31
That's a bug in 3.0.0. Please upgrade to the latest nightly build (which also happens to be a release candidate for 3.1.0).
5  Game Development / Newbie & Debugging Questions / Re: [LWJGL] 3 - Working with contexts on: 2016-10-26 10:49:07
The design of GLFW requires that all event handling happens on the main thread. So a loop that looks like:

while ( !glfwWindowShouldClose(window) ) {

    // ...

should go on the main thread.

Rendering can happen on any thread, main or secondary. You can do rendering on a secondary thread by passing the window handle to that thread and calling glfwMakeContextCurrent(window). This makes the OpenGL context associated with that window current in the secondary thread. GL.createCapabilities() will work after that and you can use the LWJGL OpenGL bindings to do rendering.
6  Java Game APIs & Engines / Engines, Libraries and Tools / Re: JOML 1.8.0 Release on: 2016-10-24 12:30:08
Actually, no. You have to force this module to be exported, I had to use this even though I don't package my software as a module:
--add-exports jdk.unsupported/jdk.internal.ref=ALL-UNNAMED

My guess is that you depend on Cleaner, which has been completely removed from sun.misc and moved to jdk.internal.ref. It has nothing to do with sun.misc.Unsafe.
7  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-10-23 22:25:05
Finished a single week project, one day late. It parses the Vulkan XML registry and asciidoc documentation and generates the LWJGL 3 Vulkan bindings. It was painful (tons of details to cover, bugs in the registry, bugs in asciidoctor, etc), but I'm hoping it'll save a lot of time (and my sanity) in the future. The Vulkan javadoc is also now much more complete and consistent.

Fun fact: The source code is 3 Kotlin files that compile to 105 Java classes.
8  Game Development / Newbie & Debugging Questions / Re: LWJGL 3 glfwSetWindowIcon does not work because I didn't use directBuff [solved] on: 2016-10-21 06:07:47
I'd almost consider putting together a Dummy's Guide to OpenGL/LWJGL just because I don't want people to struggle like me.

We recognize that this has always been an issue for new LWJGL users and will try to do something about it in the future. (see LWJGL#201)

In the meantime, my recommendation to new users is that they go through the sample code and demo suite.
9  Game Development / Newbie & Debugging Questions / Re: LWJGL 3 glfwSetWindowIcon does not work because I didn't use directBuff [solved] on: 2016-10-20 14:40:26
One obvious bug with the above code is that the ByteBuffer is not flipped after the put call. Other than that, I cannot reproduce the NPE and the code works fine for me. Could you post the entire stacktrace?

More observations:

- GLFWImage.Buffer is an array of GLFWImage structs. You don't need to allocate a GLFWImage, then copy it to the buffer. The buffer can be used as a flyweight, it exposes all methods GLFWImage has and it applies them to the current buffer position.
- In loadImageToByteBuffer, you don't need to allocate a byte[], fill it, then copy it to the ByteBuffer. You can fill the ByteBuffer directly and avoid the overhead.
- LWJGL comes with bindings to stb_image, which can be used to load a PNG file directly as a ByteBuffer. It is faster and more memory efficient than using ImageIO and BufferedImages.

This is what I would use:

try ( MemoryStack stack = stackPush() ) {
   IntBuffer w = stack.mallocInt(1);
   IntBuffer h = stack.mallocInt(1);
   IntBuffer comp = stack.mallocInt(1);

   ByteBuffer icon = stbi_load("modules/core/src/test/resources/lwjgl32.png", w, h, comp, 4);

   glfwSetWindowIcon(window, GLFWImage.mallocStack(1, stack)

10  Discussions / General Discussions / Re: GLFW Controller Database on: 2016-09-18 12:17:22

Identified as: Xbox 360 Controller
Platform: Windows 10 x64

    "layout": {
        "buttons": "14",
        "axes": "6"

    "buttons": [
        { "index": "0", "name": "A" },
        { "index": "1", "name": "B" },
        { "index": "2", "name": "X" },
        { "index": "3", "name": "Y" },

        { "index": "4", "name": "LB" },
        { "index": "5", "name": "RB" },
        { "index": "6", "name": "BACK" },
        { "index": "7", "name": "START" },

        { "index": "8", "name": "LS" },
        { "index": "9", "name": "RS" },

        { "index": "10", "name": "DPAD_UP" },
        { "index": "11", "name": "DPAD_RIGHT" },
        { "index": "12", "name": "DPAD_DOWN" },
        { "index": "13", "name": "DPAD_LEFT" }

    "axes": [
        { "index": "0", "name": "LS_X" },
        { "index": "1", "name": "LS_Y" },
        { "index": "2", "name": "RS_X" },
        { "index": "3", "name": "RS_Y" },
        { "index": "4", "name": "LTRIGGER" },
        { "index": "5", "name": "RTRIGGER" }
11  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-09-14 19:03:08
The new download page is now live. The build configurator is still under development, but Maven & Gradle script generation is working for the nightly build. Any feedback would be greatly appreciated!
12  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-08-25 14:26:39
Modular maven artifacts are now available in the snapshot repository. More details and a request for feedback, here (you may also reply in this thread if you prefer).
13  Game Development / Newbie & Debugging Questions / Re: Floatbuffer memory leak on: 2016-08-21 12:28:53
I couldn't really find any tutorials on linking stacks with lwjgl and if anyone has any please let me know.

Not sure what you're looking for exactly. It's very simple:

// Method 1: Explicit malloc/free, useful for "big" buffers and custom lifecycles 
FloatBuffer buffer = memAllocFloat(100);
// ..use buffer..
memFree(buffer); // buffer goes away (doesn't have to be in the same method)

// Method 2: Stack allocation, useful for "small" buffers, local-only
try ( MemoryStack stack = stackPush() ) {
   FloatBuffer buffer = stack.mallocFloat(100);
   // ..use buffer..
} // buffer goes away
14  Game Development / Newbie & Debugging Questions / Re: Floatbuffer memory leak on: 2016-08-21 08:22:24
when this is called it creates a float buffer and appears to leave it in memory , my test of just having a for loop call that ended up hogging memory.

The LWJGL recommendation for performance sensitive code is explicit allocation management (memAlloc/memFree methods in org.lwjgl.system.MemoryUtil) and stack allocations (org.lwjgl.system.MemoryStack). See #4 and #5 in this post for details.

Even if you explicitly invoke the Cleaner of buffers allocated via ByteBuffer.allocateDirect, performance is going to suffer in tight loops (allocateDirect itself is slow, objects always escape so more GC pressure). See this benchmark.
15  Game Development / Newbie & Debugging Questions / Re: Getting null pointer trying to load texture with LWJGL 3 w/ runnable jar on: 2016-08-19 11:20:17
I'm using

ByteBuffer data = stbi_load(file, width, height, comp, 4);

to put my png files into the game but when I create a runnable jar the app can't find my files.

The stbi_load function only works with plain image files on a filesystem. It knows nothing about the classpath and JAR files. If you really want to pack images in JARs, you'll have to do your own IO and then use stbi_load_from_memory instead.

For now I'm loading them in as BufferedImages via method call

This completely defeats the point of using stb for image IO. The LWJGL demos provide a (simple, not production-ready) method for loading resources, here. It returns a ByteBuffer with the resource contents and it works with both plain files and resources on the classpath.
16  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-08-03 11:35:03
I did the LWJGL session at JCrete yesterday. Not a great turnout, but was good fun. I got most questions from Jaroslav Tulach (NetBeans architect, now working on Truffle/Graal). Spent a bit of the afternoon with him, building Graal and exploring its source code. It sounds like it might be a great alternative to Project Panama for native interop.

Apparently he also talked to Cliff Click about it and he decided to make a session this morning on "why JNI is slow". I'm familiar with the issues and I'd seen that presentation before, so not much to learn. An interesting note was on native-to-Java callbacks: they're slow because they're always interpreted. He wasn't familiar with Panama or JNI Critical Natives. Showed him some critical native code in LWJGL at the end, I think he was a bit surprised that it actually works.

I also did a session on Kotlin today, quite a few people showed up and most of them hadn't seen it before. Not much you can do in an hour, but I think it was enough to get them started.
17  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-07-30 16:33:37
Finished packing for JCrete 2016. Super-excited, been a Java developer for 16 years and this is my first Java (un)conference. Actually, first work-related conference of any kind.

If there's interest, I'll try to do a session on LWJGL (and maybe Kotlin). Will post again if a live stream is available.
18  Game Development / Newbie & Debugging Questions / Re: LWJGL 3 glfwSetWindowIcon does not work - at all on: 2016-07-20 14:05:54
You don't necessarily need to use BufferUtils, just use BytrBuffer.allocateDirect then use the put method of the ByteBuffer to load the array data in to the buffer. BufferUtils is a useful utility method but it hides things you should really know about.

BufferUtils doesn't hide anything. It uses ByteBuffer.allocateDirect and sets the byte order to ByteOrder.nativeOrder(). Unless you're doing something very specialized (e.g. low-level networking), using the native byte order is exactly what you want. Actually, not setting the byte order has always been one of the most common issues new LWJGL users face.

As for allocateDirect itself, the post explains why avoiding it is a good idea. In LWJGL code I write, this is my decision process (from most-to-least preferred):

1) Is it a short buffer/struct that is created, used and discarded locally*? Use MemoryStack for stack allocations.
2) Is it trivial to manually free the buffer/struct? Or, is the allocation in a performance sensitive path? Use MemoryUtil for the explicit alloc/free functionality.
3) Use BufferUtils.
32767) Use ByteBuffer.allocateDirect() directly.

* "Local" could apply to any allocation with a lifetime of a single method up to a single frame (e.g. in the scope of the main loop).
19  Game Development / Newbie & Debugging Questions / Re: LWJGL 3 glfwSetWindowIcon does not work - at all on: 2016-07-19 20:29:17
You're using ByteBuffer.wrap in loadImageToByteBuffer. This returns a heap ByteBuffer, which is not supported by LWJGL 3. This post explains why.
20  Discussions / Miscellaneous Topics / Re: What I did today on: 2016-07-16 17:25:23
Wrote a post on how LWJGL 3's approach to memory management enables clean and efficient code.
21  Game Development / Articles & tutorials / Re: Basics of gamma correction on: 2016-07-10 10:51:03
Another often overlooked aspect is gamma-correct mipmap creation. For the same reasons you can't do lighting and blending calculations in gamma-space, you can't do texture filtering. The mathematically correct way to downscale sRGB textures is to first convert them to linear-space, do the filtering, then store the new mip level in sRGB again. The quality difference can be significant for many textures.

Also, do not use glGenerate(Texture)Mipmap offline. It is tuned for speed and should only be called at runtime (if ever). It doesn't do gamma-correct downscaling (unless the texture is in an sRGB format and the driver feels like it) and you have no control over filtering. If you do it manually, you can always do it in linear-space and use a high-quality filter (hint: even bicubic is not a good choice for most textures).
22  Game Development / Articles & tutorials / Re: Basics of gamma correction on: 2016-07-10 10:30:03
More reading resources:

The Importance of Terminology and sRGB Uncertainty
The sRGB Learning Curve
Effective OpenGL (pdf, sections 7, 8, 9)
UHD Color for Games (pdf)
23  Game Development / Newbie & Debugging Questions / Re: [LWJGL 3] GLFW Cursor Input on: 2016-06-29 23:52:50
The most likely reason is that you're calling GLFW functions in threads that are only supposed to be called on the main thread. Please read the GLFW documentation and make sure you follow the rules. The LWJGL javadoc on each method also mentions if it can be called on any thread or only on the main thread. If you really do everything correctly and it still doesn't work, I'd be very interested to see sample code the reproduces the problem.
24  Game Development / Newbie & Debugging Questions / Re: [LWJGL 3] GLFW Cursor Input on: 2016-06-29 18:27:55
-am I still able to get mouse movement if I use GLFW_CURSOR_DISABLED? also I am calling glfwSetCursorPos every frame so ...

Yes, you still get cursor events via the callbacks. You also don't have to call glfwSetCursorPos at all.

-but the cursor doesn't even get invisible, it just stays as usual

GLFW_CURSOR_HIDDEN hides the cursor when it passes over the client area of the window. If it moves to the border or outside the window, it is visible. Isn't that what you see?
25  Game Development / Newbie & Debugging Questions / Re: [LWJGL 3] GLFW Cursor Input on: 2016-06-29 15:48:18
Your ability to recenter the mouse depends on how often your event loop runs. In most cases, even without vsync, it's not often enough. That's why using glfwSetCursorPos is not meant to be used for centering the mouse. You should try to use glfwSetInputMode with GLFW_CURSOR_DISABLED.

A few other notes:

- Using createDoubleBuffer in a loop is not efficient. Consider stack allocation (see MemoryStack) or caching the buffers.
- You don't have to rewind() or flip() after calling LWJGL methods.
- GLFW_CURSOR_HIDDEN does not restrict mouse movement, within or outside the window. It simply makes the cursor invisible.
26  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-25 18:10:27
Build 3.0.1 #6 is now available with modular artifacts. More details and progress update here.

This is what you get with the current structure:

27  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-17 19:24:42
Progress update:

Needs a lot more work, but all tests and demos run fine.

The resulting binaries are roughly 2x the original lwjgl.dll size, because the CRT is statically linked in every module. It shouldn't be a problem if only a subset of them is used. Some may be merged into the core library, they're tiny without the CRT. For example JAWT and jemalloc add about 1kb to lwjgl.dll, but are 83kb and 84kb standalone (note: this is just for the JNI functions, not the libraries themselves). The corresponding modules will still be optional.
28  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 15:30:22
I think you're being a little defensive about my observations, Spasi! I'm quite aware of the 3.0.1 goals already.

I guessed so, I'm just trying to address your concerns in a way that will be understandable to everyone reading. I fully appreciate your input btw!

It's a pity to de-motivate the project lead like that.

Don't worry, there's no demotivation going on. Cas has strong opinions and gives honest advice. It's always helpful.
29  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 15:21:46
it appears to be largely driven by you and your own personal needs and as such seems to me to have become a giant git repository with all of your open source work in it.

Let's be fair here.

LWJGL 2 bindings that we ought to have in LWJGL 3:

- OpenAL
- OpenCL
- OpenGL
- OpenGL ES

Bindings that were absolutely necessary in LWJGL 3:

- GLFW (Display + input API replacement)
- Vulkan (a good match for LWJGL and also the most user requested API)
- dyncall (FFI + dynamically generated native-to-Java callbacks)
- Basic system calls

Bindings requested by users:

- LibOVR (Oculus SDK)
- NanoVG
- SSE(3)
- Misc system calls

Bindings that I added without anyone asking, but everyone agreed were extremely useful:

- jemalloc
- stb (image IO, font rendering, vorbis decoding, etc)

Bindings that I added without anyone asking, are not that exciting, but try to solve real problems LWJGL users face:

- NativeFileDialog
- Nuklear
- libstem_gamepad (in a branch, failed experiment, to satisfy concerns about GLFW's gamepad support)

Bindings that I added without anyone asking, either from curiosity or because I needed them for personal work:

- xxHash (tiny & fast non-cryptographic hash functions)
- LMDB (post 3.0.0)
- ODBC (mostly complete branch)
- hwloc (incomplete branch)

I hope it's obvious that the majority of the work I did was driven by user needs. The only personal binding that made it to 3.0.0 is negligible compared to the rest.

What it definitely isn't, modular or not, is a lightweight Java games/graphics library! It's no longer a lightweight project as it covers everything from GUIs to compute to audio to in-memory databases to hacking the Java language to get structs in.

I would argue that it is indeed lightweight because it doesn't do anything. None of the APIs or functionality provided by LWJGL has been designed or written by LWJGL developers. The only thing the LWJGL core provides is a half-decent way to interact with native APIs and data from Java/JVM.

Also, why is any of the above an issue if #100 allows you to download LWJGL core, GLFW, OpenGL and OpenAL and nothing else?

It's not Java any more as it now contains multiple binary libraries. It's not a single library now but a whole multitude of libraries.

I don't get this. Why does it matter how many binaries there are? Deployment issues are a thing of the past with the SharedLibraryLoader. LWJGL 2 also had two native binaries (lwjgl + OpenAL Soft), now there are 2 more (GLFW and the optional jemalloc). How's that less Java than before?

What LWJGL 3 is now is a vast collection of bindings, most of which are irrelevant to most people. What this means is that maintenance effort is going to be simply non-existent on it, and once you (eventually) grow tired of it, and you will, it'll just stagnate and get bitrot and become a large legacy which will distract people from otherwise creating separate efforts to solve specific issues.

There is a very critical difference. Once Elias stopped working on LWJGL we were screwed, because there was no one with the experience to improve/fix the OS-specific functionality. There's no expertise required to maintain LWJGL 3. Someone has a problem with GLFW? Open an issue on their github and (if it's legit) elmindreda will fix it eventually. It's not our problem anymore.

I lost interest in maintaining LWJGL after a few years of developing on it, largely because it did everything I needed it to by that point, and also because I was seeing virtually no return on my efforts. I watched Markus accumulate two and a half billion dollars on the back of the literally months and months of effort I'd put in on the library he used to catapult himself into the realms of the unspeakably rich with barely so much as a thankyou, and that, for me, was the point at which I decided I couldn't be arsed with open source any more. I only have so much time left in the world and a lot of things I'd like to do, and making Markus richer wasn't on the list, so I diverted my efforts elsewhere. At some point, you too will find something more interesting and distracting, and you'll be leaving behind a huge, huge pile of stuff which no-one except you really cares too much about.

Oh, I do have something a lot more interesting to work on. Wink That's why I've put a huge effort into making LWJGL 3 easily maintanable.

On seeing a return on open-source efforts... I don't know, that's not what open-source is about I guess. I even removed the option to donate to LWJGL when I took over. Didn't feel right without having something to deliver. On the other hand, what we have been doing in LWJGL isn't just open-source... Writing JNI bindings is on its own level of masochism. It's the kind of open-source that no one wants to be doing. That usually has value. When my wife asks what I'm doing, I wish I had something better to say than "omg I'm writing Vulkan bindings, do you know how IMPORTANT this is?". Especially with the economy in Greece being what it is.

On Minecraft, I cannot claim any credit for what LWJGL was when Minecraft happened. Maybe Cas is right, I don't know. What I do know is that post-Minecraft success, its users had lots of trouble because of LWJGL and we didn't do much for them. We never had much of a contact with Marcus or their devs either, which I found strange given how critical LWJGL was for the game. Strange situation.

I strongly advise you to split LWJGL up into the bare minimum and then create separate, independent projects that build on top of or besides LWJGL for GUI libraries, structs, OpenCL, in-memory databases, vector math, etc.

Having everything in the same repo, in branches, or in different repos, is just a technicality. The only thing that matters is how the software is deployed. With #100 + a few other ideas we had recently, I believe everyone will be satisfied.
30  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - LMDB bindings on: 2016-06-07 10:33:53
I might actually rip a lot out of the jar if thats the case.

This is possible and some users do it. You can remove any binding package you don't need from lwjgl.jar and you can also delete the jemalloc/GLFW/OpenAL shared libraries. #100 will make it so that you don't have to do it manually and will also split the lwjgl shared library itself (which contains the core functionality + statically linked bindings).
Pages: [1] 2 3 ... 35
theagentd (26 views)
2016-10-24 17:51:53

theagentd (26 views)
2016-10-24 17:50:08

theagentd (26 views)
2016-10-24 17:43:15

CommanderKeith (45 views)
2016-10-22 15:22:05

Roquen (48 views)
2016-10-22 01:57:43

Roquen (58 views)
2016-10-17 12:09:13

Roquen (57 views)
2016-10-17 12:07:20

Icecore (75 views)
2016-10-15 19:51:22

theagentd (339 views)
2016-10-04 17:29:37

theagentd (342 views)
2016-10-04 17:27:27
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!