How to solve LWJGL3 work arounds ?

Started by JackDawson, June 01, 2015, 12:08:25

Previous topic - Next topic

JackDawson

Hello everyone. I went through this forum and since LWJGL version 3 is fairly new, the problems I have to figure out are also new.

I have been using LWJGL 2.9.x and I updated to the LWJGL 3 ( Stable Version ) and I am not sure if this was a smart move or not. But here is the problem before me. I am trying to find work arounds. But I am not exactly sure how to go about doing that since all my web searching keeps bringing me here to this forum. So I am here to see if anyone has any ideas here.

Here are what I am running into at this time.

For these two here I get the error "Can not make a static reference to a non-static method getCapabilities() from the GLContext"

GLContext.getCapabilities().GL_EXT_texture_mirror_clamp

GLContext.getCapabilities().GL_EXT_secondary_color


another error I now get is this...
"The method glLoadMatrix(floatBuffer) is undefined for the type GL11"
GL11.glLoadMatrix()


And still another two....
Both of these used to take two parameters, now they are only taking one. And this changes everything about the code.
GL11.glGetFloat
GL11.glGetInteger

All of these methods work in 2.9.x. But once you update to 3.x they no longer work as you can see.

My problem here is, I am not sure on how to go about fixing this. Are there others who found work arounds ? Are there forum pages that I just couldn't find that has already solved this ? I am willing to do the research, I just am confused on where to go to do it.

What would be nice is if there is a page somewhere that shows Legacy vs the Work-A-Round.

Kai

All of your problems are really easy to fix.
And, yes, switching to LWJGL version 3 IS a smart move. :)

The method GLContext.getCapabilities() is now an "instance method," which means it must be invoked on an instance of type GLContext.
Look at line 93 of this example.
The static method "createFromCurrent()" creates a GLContext assuming a native context is current, which will be made current by GLFW.
This call also returns an object of type GLContext.

GL11.glLoadMatrix(FloatBuffer) is now: GL11.glLoadMatrixf

GL11.glGetFloat with two parameters became: GL11.glGetFloatv
Additionally, if you only expect a single float to be returned by glGetFloat, there is now the convenience method GL11.glGetFloat(int)

And nothing of these are "work-arounds", just API changes to more closely reflect the native OpenGL functions.

JackDawson

Thank you for the info. That solved about 3 of my 5 problems. Is there a page that shows what Legacy vs Work-A-Rounds they have made ?

Also, I am seeing that the GLContext.getCapabilities() that you reference here is using GLFW. Is GLFW now being forced on us to use ? I do not want to use that library. I like the simplicity of just simple LWJGL. Or is that just for that example code only ?

After reading your reply, it makes sense about defining variables and floats according to the method used. But the GLContext.getCapabilities() method as an instance, that part eludes me. That is what I have yet to fix.

Thank you for the reply thus far.

EDIT UPDATE: What I am currently testing against are the two methods that return a boolean of true or false if those two extensions do exist for the openGL version running.

Speaking of course about the two I listed in the first post.
GLContext.getCapabilities().GL_EXT_texture_mirror_clamp

GLContext.getCapabilities().GL_EXT_secondary_color

If these two exist they return true.

Kai

Quote from: JackDawson on June 01, 2015, 12:30:58
But the GLContext.getCapabilities() method as an instance, that part eludes me. That is what I have yet to fix.
Sorry about that misunderstanding.
I was assuming that you are familiar with the Java programming language, or object-oriented programming in general, to the extents as to know the difference between a "static method" and an "instance method."

You know, GLContext.getCapabilities() in LWJGL 2 was a "static method," meaning that you would not have needed to create an object/instance of GLContext in order to call that method. You would call it directly on the "class" it was defined in.
Now with LWJGL 3 things have slightly changed and that method became an "instance method," meaning that you would now have to obtain an object/instance of a GLContext from somewhere in order to call that "getCapabilities()" method on it. And that "somewhere" is now GLContext.createFromCurrent() which will hand you (as its return value) an instance/object of type GLContext on which you can then invoke "glGetCapabilities()".
I hope that made it clearer.

As for GLFW: You do not have to integrate GLFW using any "additional" third-party library (jar or shared library) . GLFW is bundled with LWJGL 3 and is the very preferred way to interface with the window manager and to create OpenGL contexts.

spasi

There is also the static GL.getCapabilities(), which is similar to LWJGL 2's GLContext.getCapabilities(). It will retrieve the current GLContext in the current thread and return its getCapabilities().

JackDawson

Thank you both for all of your help. This has been very educational already. Yes I am still fairly new to the way Java works. I have to keep pounding this info into my old brain. lol

The GLContext.getCapabilities() changing to GL.getCapabilities() change worked. Thank you. :)

Will there ever be a page that will show the work arounds for upgrading from 2.x to 3.x ?

EDIT UPDATE : And thank you for the info about GLFW. I didn't know it was integrated. That Is better then 15 libraries all over the folder..  All in one I like very much. :)

Kai

A few lines of code tell more than a thousand words...
// Obtain context "once" in the application and store somewhere
GLContext ctx = GLContext.createFromCurrent();
...
// Query capabilities "once"
GLCapabilities caps = ctx.getCapabilities();
if (caps.GL_EXT_texture_mirror_clamp) {
  // do this
}
if (caps.GL_EXT_secondary_color) {
  // do that
}

JackDawson

That is awesome !!  Thank you. :)

I can see that this is actually less coding then I previously had to do. Impressive work LWJGL3 has done. I am very happy to see this library advance. Thank you once again. :)

Kai

Just because this will pop up rather soon:
If at some point you are searching for the missing gluLookAt() or gluPerspective() (which LWJGL 2 did provide in its util jar) then you can have a look at the pure-Java math library JOML, which Neoptolemus and I created to help Java- and LWJGL-people with vector and matrix calculations.
Have a look at this GitHub repository site or directly download the latest release.

JackDawson

Quote from: Kai on June 01, 2015, 13:13:40
Just because this will pop up rather soon:
If at some point you are searching for the missing gluLookAt() or gluPerspective() (which LWJGL 2 did provide in its util jar) then you can have a look at the pure-Java math library JOML, which Neoptolemus and I created to help Java- and LWJGL-people with vector and matrix calculations.
Have a look at this GitHub repository site or directly download the latest release.

Haha, you read my mind. I was about to ask about this. Thanks again for the info. :)

Kai

Hehe, no, you just came to the exact right time, since JOML in its current form basically only has existed since... well... yesterday. :)

kappa

Quote from: Kai on June 01, 2015, 13:36:28
Hehe, no, you just came to the exact right time, since JOML in its current form basically only has existed since... well... yesterday. :)
Its already been tweeted by OpenGL. :)

JackDawson

Quote from: Kai on June 01, 2015, 13:36:28
Hehe, no, you just came to the exact right time, since JOML in its current form basically only has existed since... well... yesterday. :)

Just so you are aware, I was able to fix a lot of the errors, but the two methods that are about the gdxMatrix using the VAL[] array is not identifiable. So I just commented those two methods out for now.

Both are in the Matrix4f class. Just FYI.

Kai

Yes, if you are building JOML from source within your IDE and are not using Maven for dependency resolution, you will get compiler resolution errors with those interoperability methods that reference those external library classes, like javax.vecmath, LWJGL2 util vector and libGDX.
If you switch to using Maven when including JOML as a project in your IDE's workspace, the dependencies should be downloaded via Maven, dependency resolution should work just fine and JOML should build from source.
If you are using JOML from its jar distribution within the classpath of your own application, you should not have any compiler issues as long as you don't invoke those interop methods.
To emphasize on the last part: Those external libraries are not a required runtime dependency of JOML. They only exist and can be invoked if you happen to use any of the other third party libraries.

JackDawson

So far the only dependency I am seeing is the gdxLib. The other two were solvable as they are built into Java.

But thank you for the info about Maven. That definitely could come in handy.

Back to the subject of LWJGL3..
I read somewhere that AWT is deprecated or is going to be deprecated in Java do to limits it had on other operating systems other then windows. Is this true ? If so, is there an alternative ? Is this the reason for GLFW ? If so, am I supposed to setup the Display with GLFW now ?

Here is the tutorial on the LWJGL Tutorial page. Now it works fine under 2.9.x.. but under 3.x it has no references to most of those functions. And there is one option that I could use AWT.. which again, my goal here is to work with latest update and the correct way of doing things. So I am asking what is deprecated. This again is another reason to have a legacy 2.9x vs 3.x conversion page.

My question is mainly about the Display.

http://wiki.lwjgl.org/wiki/Version_selection

Thank you once again for all input so far. This has already been a good day. :)

EDIT UPDATE : I best clarify my question..  I can use this page as the example that was shown above..

http://www.lwjgl.org/guide

But the question is about AWT. Is this ok to use ? This all has to do with the display.