Hello Guest

Missing GL_SRC1_ALPHA and problem with ARB extensions

  • 2 Replies
  • 6175 Views
Missing GL_SRC1_ALPHA and problem with ARB extensions
« on: December 19, 2015, 21:25:29 »
First of all, GL33 is missing GL_SRC1_ALPHA. With that out of the way...


So, I'm not entirely sure what the correct behavior here should be, but I can say that it has changed somewhat from LWJGL 2. In LWJGL 2, I used the GL** classes for everything, even when the context technically didn't support that OpenGL version and only supported that function through extensions. With LWJGL 3 core profiles there's a check in place that prevents that, so I have to use the extension. This can cause problems since the extensions are very inconsistent with if they keep the ARB/EXT/NV/AMD/etc suffixes for the function names. In my opinion they should always KEEP them, as otherwise you get collisions.

Example:
Code: [Select]

import static org.lwjgl.opengl.GL30.*;
import static org.lwjgl.opengl.ARBFramebufferObject.*;

if(capabilities.OpenGL33){
    glBindFramebuffer(...); //Use GL30 version
    //OpenGL 3.3 version of code
}else{
    glBindFramebuffer(...); //Use ARBFramebufferObject version
    //OpenGL 2.1 version of code
}

The above causes a static import collision, which is frustrating. From what I can tell, ARB extensions do not have the ARB suffix (glBindFramebufferARB()) like EXT/NV/AMD extensions have. What are your thoughts on how to solve this?

*

Kai


*

Offline spasi

  • *****
  • 2261
    • WebHotelier
Re: Missing GL_SRC1_ALPHA and problem with ARB extensions
« Reply #2 on: December 20, 2015, 19:52:25 »
In LWJGL 2, I used the GL** classes for everything, even when the context technically didn't support that OpenGL version and only supported that function through extensions. With LWJGL 3 core profiles there's a check in place that prevents that, so I have to use the extension.

I see what you mean and it indeed has changed in LWJGL 3. It was convenient in LWJGL 2, but you had the risk of using unsupported functionality (the static import included everything from that GL version). I believe the LWJGL 3 design is cleaner and safer.

This can cause problems since the extensions are very inconsistent with if they keep the ARB/EXT/NV/AMD/etc suffixes for the function names. In my opinion they should always KEEP them, as otherwise you get collisions.

Example:
Code: [Select]

import static org.lwjgl.opengl.GL30.*;
import static org.lwjgl.opengl.ARBFramebufferObject.*;

if(capabilities.OpenGL33){
    glBindFramebuffer(...); //Use GL30 version
    //OpenGL 3.3 version of code
}else{
    glBindFramebuffer(...); //Use ARBFramebufferObject version
    //OpenGL 2.1 version of code
}

The above causes a static import collision, which is frustrating. From what I can tell, ARB extensions do not have the ARB suffix (glBindFramebufferARB()) like EXT/NV/AMD extensions have. What are your thoughts on how to solve this?

There's no rule here. There are many ARB extensions with a suffix and many without one. The ARB extensions without a suffix are extensions that were released at the same time as a new OpenGL version, for implementations that couldn't fully support that particular version but could still support parts of it.

Just so there's no misunderstanding, it's not an LWJGL decision whether there's a suffix or not. It's just how the extension is defined in the specification.

There are two solutions to this:

- Don't use static imports when you mix core and extension functionality of the same thing in the same class. Or use a static import for the core version and a normal import for the extension. You can use the tokens from the core version (they are the same values), so you only have to prefix the extension functions.

- Don't use the two implementations in the same class/method. In my code I usually create an interface that abstracts the extension functionality and write two implementations (one using the core version, one the extension). In any execution of the program, only one of the two implementations will be instantiated, which produces fully inlineable code. The abstraction is free.