Hello Guest

Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Vulkan / Re: Vulkan UBO management -
« Last post by hydos06 on March 19, 2020, 06:00:08 »
bump :p
22
OpenGL / Re: Rendering process clarification needed
« Last post by Aisaaax on March 18, 2020, 06:44:34 »
A quick reply to anyone concerned.

Every rendering call indeed renders the full buffer. Then the mixing occurs, determined either by depth buffer, glBlendFunc, and glBlendEquation

There are examples online to see how those functions work. But basically, there is no performance advantage in rendering one way or the other.
23
Lightweight Java Gaming Library / Re: Project panama
« Last post by spasi on March 17, 2020, 16:29:09 »
I'm still following Panama's progress, but I will not start testing until it stabilizes. There are still too many API changes happening and the promised performance isn't there.

The latest bad news is that they're trying to shoehorn safety features into the memory access API. Which is hopeless without a) sacrificing performance or b) copying something like Rust (impossible). Not saying it's not a noble effort, but it will take more and more time to sort it all out. I would have preferred just being able to write C in Java (same semantics, same unsafety, same performance), then letting libraries like LWJGL handle and hide the nasty stuff.

On the performance front, there are still too many open issues with Hotspot that affect Panama performance, who knows when and if they'll be fixed.

And, as always, we're still waiting for Valhalla, which imho is a prerequisite for Panama to turn out nice. The good news is that I personally trust the engineers involved and they'll eventually figure out the best approach for both projects. However, the design and implementation issues are extremely hard and the process necessarily time-consuming.
24
Lightweight Java Gaming Library / Re: Project panama
« Last post by tlf30 on March 17, 2020, 15:24:23 »
@Spasi, I was just checking up on the Panama project. It looks like they have made a lot of progress, but trying to find a roadmap for them is like pulling teeth.
Have you heard of any timeline for them? What are your thoughts on their progress?

Thanks,
Trevor
25
Hi,
   I've been working on using OpenGLES 3with OpenVR and LWJGL3 (3.2.3), but when I issue the submit to the compositor, I'm getting error 105 (VRCompositorError_TextureUsesUnsupportedFormat).

   I've just ported the code to OpenGL 4, and the submission works fine.

   It's hard at this point to say whether this is an LWJGL3, SteamVR or NVIDIA driver problem! I've reported it in the SteamVR developers forum but am getting nothing from there.

   The code is here: https://github.com/hdonk/lwjgl_vr_framework . The OpenGL version is in the OpenGL branch

   Any suggestion on how to proceed with debugging the OpenGLES version?

Cheers,
Nick
26
Vulkan / VK10.VK_VERSION_MAJOR can return negative values
« Last post by juha on March 16, 2020, 09:38:18 »

This appears to be a minor issue but came up with value range testing:

VK10.VK_VERSION_MAJOR can return negative integer. The assumption is all returned values are positive due to underlying C99 API using unsigned integers.

The following code will return signed value -512 instead of the expected value 512:

Code: [Select]
System.err.println(VK10.VK_VERSION_MAJOR(0x80000000));

> -512

Assuming we've not misunderstood the intended bit manipulation operations, the (decompiled) implementation of VK_VERSION_MAJOR should use Java's unsigned bit shift operation '>>>' instead of the signed right shift operation '>>':

Code: [Select]
  public static int VK_VERSION_MAJOR(@NativeType("uint32_t") int version)
  {
    return version >>> 22;
  }

Or alternatively use bit-wise AND mask to drop the signed bit:

Code: [Select]
  public static int VK_VERSION_MAJOR(@NativeType("uint32_t") int version)
  {
    return version >> 22 & 1023;
  }

Given the current code does yield 512 distinct *major* versions, this is probably not a high priority issue for anyone at the moment :-)


27
Hello all
im trying to learn lwjgl 3 lib and 3d in general
can you please point me to free open source 3d games that i can learn from ?
thanks
28
OpenGL / Re: "Rendering without vertices"
« Last post by Aisaaax on March 13, 2020, 03:46:28 »
Because it's cool?
Or because they have a specific task that doesn't really need vertexes?

I don't know. Why don't you ask them directly what are the benefits?

Shadertoy, for example, is a community dedicated to shaders and it stands to reason that they focus on pushing the boundaries of what can be done with them. Does it have any practical purpose other than learning? Not really. It's done just to show off and make something cool but useless.

Just because someone does something doesn't mean that it has some practical purpose. Often it's just for fun.

Again, can you render without vertexes? Yes. Not everything, but yes. Is it practical? No.
If it was practical, then there would be suits and API's that are focused on vertex-less engines. Big companies would adopt that paradigm, especially those that favor efficiency above else.

But it is NOT efficient. Both in computing time, and in the time it takes a developer to write something and make it work.

If you think I'm wrong - hey, I may be! But then you should take your question to those communities themselves and ask them what's the benefit.
29
OpenGL / Re: "Rendering without vertices"
« Last post by overlisted on March 13, 2020, 01:09:04 »
While rendering without vertexes is very possible, it is FAR from efficient.

The thing here is, that it boils down to writing very complicated and convoluted fragment shaders. This approach, while cool in theory, has massive drawbacks.
- It is hard to debug
- It is very inefficient as far as processing time goes.

Basically, you need to run a very complex algorithm for every single fragment on your screen to determine its color. As you can imagine, this means repeating your calculations hundreds of thousands of times, even for a 720p render. For each frame.

Furthermore, while I never studied this in-depth, I believe there are limitations to what exactly you can do with it. Many GPU's, especially on mobile, have a limit to how many instructions long they can be. And if you want to create something like an animated character, you have to basically emulate vertexes to at least some extent within your fragment shader, so you can keep track where his limbs are and his position on the screen. So you return to vertexes, only in the least efficient way.

That's what I think about it. I may be very wrong here. But I personally think that it's a cool exercise and nothing more. Essentially, it's a waste of time that has only bragging rights for benefits.
There is a reason why all modern rendering is vertex-based and texture-based and polygon-based. Because it greatly reduces the processing needed, and as such lets you do more MEANINGFUL calculations.

But why do Shadertoy and GLSL sandbox use that method of rendering?
30
Lightweight Java Gaming Library / Adding native library that uses opengl
« Last post by Balint66 on March 11, 2020, 12:10:18 »
Hello!

I'm new to the forum so if I'm posting in the wrong place then feel free correct me and point me to the right place to post my question. 🙂

So here comes my problem: I have a native library that uses the current opengl context on the thread but it's unable to access it by the way I implemented it.

First I tried to use the library with JNA and then start working with its methods but several errors occured.

Now I decided to start from scratch and doing it the right way.

Now how can I do that in the "lwjgl" way?

I'm ready to write the mappings for the funkcions (or create generator functions 😅) so that is not a problem.

Thank you for your help in advance!
Pages: 1 2 [3] 4 5 ... 10