Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (707)
Games in Android Showcase (206)
games submitted by our members
Games in WIP (781)
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 glGenVertexArrays jvm crash on: 2017-01-12 14:10:28
on some systems

Sounds like you might be calling glGenVertexArrays without checking if OpenGL 3.0 is available.
2  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.1 on: 2016-12-27 19:49:44
LWJGL 3.1.1 has been released!

Release notes
3  Game Development / Newbie & Debugging Questions / Re: LWJGL2 using LWJGL3's image loading on: 2016-12-21 12:18:38
The class incompatibilities can be solved by using a separate ClassLoader for LWJGL 3.

The native library name is not a problem either. You can rename it in the jar and use -Dorg.lwjgl.libname to specify the new name.

But then you get into some wankery with System.loadLibrary that I didn't have the patience to solve. For something like this, I'd use a separate JVM and an IPC solution to transfer data.
4  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL3 and Android Redux on: 2016-12-20 20:38:28
Hey, quick reply (I had a minor operation today and am in a bit of pain atm):

I still haven't done any work on ARM/Android, but I have new information to share. @KaiHH has been working hard to make JOML perform nicely on Android (it's being used in Samsung's GearVR SDK) and I asked him to do a bit of testing for me. Turns out that, indeed, starting with Android N and the OpenJDK-based SDK, the current LWJGL design might be viable. Unsafe seems to be a lot faster at least.

I've got tons of devices with each generation of GPU and would be glad to test, refine, and work on any necessary optimizations.

That's great, will be very helpful.

So since I only have a cursory overview of LWJGL3 from poking through the source code I'd be curious to hear what you think will be the pain points? How are you handling JDK9 removal of sun.misc.Unsafe?

LWJGL 3 depends on Unsafe and escape analysis for extreme performance. Workarounds may be possible, but at the expense of clean code.

JDK 9 does not remove sun.misc.Unsafe and it's available to all modules (there's a new, much more powerful, Unsafe in 9 that is available only inside the JDK). As of this commit LWJGL 3 also works on JDK 9 b148+, which introduced a lot of significant changes to the module system.
5  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL uses wrong graphics card on: 2016-12-12 21:23:03
The AMD equivalent:

int AmdPowerXpressRequestHighPerformance = 1;
6  Discussions / General Discussions / Re: Animation Model format - LWJGL 3.1 on: 2016-12-06 18:36:49
1. What can be considered the best format to work with animations using opengl?

There are many formats that can do the job. My personal favorite was dotXSI, but Autodesk bought and killed Softimage 3D, so...

The hardest part is setting up a decent pipeline between your artists and your engine. The actual format used to get data out of your DCC app is not very important.

2. There is any Java library to work / load this models?

LWJGL recently added assimp bindings (currently available in the nightly builds). Here's a tutorial on how to import Blender animations using assimp.
7  Java Game APIs & Engines / Engines, Libraries and Tools / Re: LWJGL 3 - Assimp bindings on: 2016-11-30 12:41:32
Good job guys!

This is awesome!

But you kinda made elect's work on jAssimp obsolete...?

Well, let's say it's good to have alternatives, because each solution has its pro and vs

A binding is relatively fast to implement and is almost change independent

but a pure port has three main advantages, you are under the optimization of the jvm, your whole memory is being managed by the garbage collector and it is available for all those who don't use lwjgl 3.1.1 build5 +. On the other side, of course, it's slower to implement and you need to keep it up with the cpp version, although most of the changes are being done on the last formats

I personally didn't know jAssimp was being worked on. I, too, would love to be able to use a Java library given the choice, especially one written in Kotlin (my language of choice these days). Where it makes sense. IMHO it makes zero sense in this case. There's only one advantage to using a Java library for loading 3D scenes:

- The API is nicer.

OK, so what? Is this the bottleneck when developing a graphics app or game? How much time you'll spend writing your model loading code? The disadvantages:

- You have to write a ton of code to create a replica of something that already exists.
- You have to spend countless hours designing the API and fixing bugs in your implementation.
- You have to do a ton of work to maintain it after it's done.
- If you do add new features, you're doing a disservice to the open source community. If you contributed to the original project instead, all downstream users would benefit.
- Hotspot is magic and GC is magic and we love them both, but doing IO and loading resources is exactly the workload where there's absolutely no benefit to using a JIT and managed memory. All resources associated with a native loader are gone when you're done, but with a Java implementation the JVM has loaded a lot of Java code, has wasted a lot of time optimizing it... and then it's just stays there. Besides, do you really think it's easy to beat a native implementation (in both CPU time and especially memory overhead) with pure Java? Not saying it's impossible, but is this the best use of a developer's time?

Finally, I'd like to address the comment on availability. You don't have to "use LWJGL" to use LWJGL's assimp bindings. The library is now modular, you can choose to use the set of bindings you need and nothing else. If that means assimp only, then yes, that works fine.
8  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3 - Assimp bindings on: 2016-11-27 09:43:35
The latest LWJGL snapshot (3.1.1 build 5) includes bindings to Assimp, a library to import and export various well-known 3D model formats in a uniform manner. It also features various post processing tools, including frequently-needed operations such as computing normal and tangent vectors, ACMR optimization, etc.

The build that comes with LWJGL includes all supported file formats (about 40 of them), so the shared libraries are bigger than usual. Assimp supports cmake, so you can easily create a custom build that includes only the formats you need, making it much smaller. You can then drop it in LWJGL and it will work just fine.

The bindings were contributed by SHC, many thanks to him!
9  Java Game APIs & Engines / Engines, Libraries and Tools / LWJGL 3.1.0 on: 2016-10-30 21:59:30
LWJGL 3.1.0 has been released!

Release notes
10  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.
11  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.
12  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.
13  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).
14  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.
15  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.
16  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.
17  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.
18  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)

19  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" }
20  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!
21  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).
22  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
23  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.
24  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.
25  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.
26  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.
27  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).
28  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.
29  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.
30  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).
Pages: [1] 2 3 ... 35
Galdo (303 views)
2017-01-12 13:44:09

Archive (464 views)
2017-01-02 05:31:41

0AndrewShepherd0 (924 views)
2016-12-16 03:58:39

0AndrewShepherd0 (864 views)
2016-12-15 21:50:57

Lunch (996 views)
2016-12-06 16:01:40

ral0r2 (1227 views)
2016-11-23 16:08:26

ClaasJG (1328 views)
2016-11-10 17:36:32

CoffeeChemist (1345 views)
2016-11-05 00:46:53

jay4842 (1426 views)
2016-11-01 19:04:52

theagentd (1226 views)
2016-10-24 17:51:53
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!