Hello Guest

Recent Posts

Pages: [1] 2 3 ... 10
I don't think you can simply take and change the interpolation algorithm for the fragments. The only way of achieving your "middle color" is probably by subdividing your quad, i.e. turning your quad into 4 quads, then you'd be able to change the middle intersection vertex of these four quads.

Or another way, probably is possible to pass in UVs, and then based on UVs to implement color blending with some special color in the middle, but that sounds more difficult than subdividing IMO.
After multiple changes to the code base, I decided to go back and try solving it again, and it magically got fixed! I went back through 200+ commits or something to see what have fixed this issue. What fixed the issue is changing one of the (color) VBO's attributes from 3 unsigned bytes to 4 unsigned bytes...  :o

I don't know what exactly is macOS' issue with it, but my best guess it's due to an odd attribute size? It was 3 floats (vertex), 3 floats (normal), 2 floats (UV), 3 unsigned bytes (color), so that's like 35 bytes. After fix (adding extra byte for color (alpha)) it becomes 36 bytes.

It's sort of makes sense, I guess. Anyways, if anyone encounters this issue, changing VBO attributes total bytes per vertex to an even number, probably.  ;D

If anyone knows why it happens, I would love to hear the reason why.
Lightweight Java Gaming Library / Re: Understanding the Gamepad-Mapping
« Last post by Lintfordpickle on February 02, 2023, 22:11:06 »
for the functionality which is mapped from other libraries, you'd be better off just using the original documentation. In this case, the glfwGetGamepadState is pretty well described here: https://www.glfw.org/docs/latest/input.html#gamepad

as for how to use it within Java, you just need to instantiate a ByteBuffer object, which will be filled with the state of the gamepad and create a new instance of GLFWGamepadState.

Code: [Select]
mDataByteBuffer = MemoryUtil.memAlloc(GLFWGamepadState.SIZEOF);
mGamepadState = new GLFWGamepadState(mDataByteBuffer);

You can then poll the gamepad state when you're handling input like this:

Code: [Select]

Not all controllers have a gamepad-mapping available, so you first need to check the availability of the mapping by calling glfwJoystickIsGamepad
Hey mitchoaa,

The enqueue methods in LWJGL are direct calls to the OpenCL driver. There's nothing complicated going on, just plain JNI passing the Java arguments directly to the native function. There must be something else in the Scala program that causes this, that does not happen in the C version.

Also, when comparing Java vs C timings, make sure the Java code is sufficiently warmed up.
The topic may be confusing, let me explain it:

When rendering in Minecraft, Mojang uses vertex rendering to render squares and textures, so I should only use vertex rendering. And the problem comes right away:
When rendering with some given vertices, the vertex shaders will decide the final position and color of the vertices and the fragment shaders will decide how the colors blend on the screen, right? However, I found modifying these files cannot change the middle colors produced when vertex rendering, which means, after the processing of the vertices by vertex shaders, the color of each pixel will be passed through a simple interpolating algorithm and then be directly passed to the fragment shaders. I cannot find any way to change how the middle colors are calculated and passed, or how to change the interpolating algorithm.

Is there any way to change the default interpolating algorithm to anything else? For example, replace the interpolating algorithm with a pigment-based blending algorithm or an algorithm to mix the colors with an additional ratio to produce a non-linear gradient. I have all these algorithms but just lack at the knowledge of OpenGL rendering, and cannot find a way to change the interpolating algorithm after days of searching. I'll be no more appreciate if anyone could answer it!

I made the image below to briefly show my question and my understanding of the render process.
OpenGL / Disable GPU timeout
« Last post by Imagyx on January 31, 2023, 08:32:07 »
Hello everyone.

I have compute shaders for gpgpu-calculations that need seconds (in the future maybe minutes) to complete and I think they crash only because of a timeout problem.
I found a setting (D3D11_CREATE_DEVICE_DISABLE_GPU_TIMEOUT, see https://stackoverflow.com/questions/32632409/while-loop-in-compute-shader-is-crashing-my-video-card-driver) which should be set to allow shaders to run longer than a few seconds.
But I don't know how to set it with LWJGL, I cannot find the right import to use.
If someone already uses this, please tell me how.

Thanks in advance and best regards.
Lightweight Java Gaming Library / Old IRC log lwjgl
« Last post by Kaje on January 20, 2023, 09:53:13 »
Hello, everyone. I don't know if this is the right place here to ask for this, but I've been looking for the old lwjgl IRC archive from around 2007-2010. Unfortunately, while WebArchive has some of echelog.com archived, many sites are gone forever. Does anyone still have the archive somewhere online or, at least, locally available? I would really be grateful if anyone still has it. I have been looking for an old chat message of mine and some friends I talked to long ago, but forgot their nicknames of.

Hey jakethesnake,

The event handling and key mapping logic lives entirely in GLFW, there's nothing in LWJGL's side that may affect it. It can be verified by running the native events test.

You'll likely have more luck reporting this to the GLFW github repo.

Many thanks!
Hey jakethesnake,

The event handling and key mapping logic lives entirely in GLFW, there's nothing in LWJGL's side that may affect it. It can be verified by running the native events test.

You'll likely have more luck reporting this to the GLFW github repo.
As the title says. I have a user on linux, using KDE to remap his Esc and caps lock buttons. This is remapping is not registered in the GLFW wrapper, and the default bindings are registered.

This seems to be an issue in both LWJGL 3.2 and 3.1

This seem to occur in both GLFWKeyCallback (the key parameter, haven't looked at the scancode) and GLFWCharCallback

I've tried to find something similar in the GLFW bug forums, but to no avail. Just want confirmation that this is indeed a GLFW bug.
Pages: [1] 2 3 ... 10