LWJGL3

106 views
Skip to first unread message

Michael Bayne

unread,
Dec 21, 2015, 2:56:19 PM12/21/15
to pl...@googlegroups.com
Ahoy PlayN people,

I just pushed a rewritten Java backend based on LWJGL3 (we used to use LWJGL2). LWJGL3 is itself pretty close to a total rewrite, but it is a vast improvement over LWJGL2 in many ways.

Anyhow, for the most part, this should be totally invisible to users of PlayN. The public API hasn't changed. The only thing that will cause trouble is that when running the Java backend on a Mac: it is now necessary to pass -XstartOnFirstThread to the JVM when running the app.

The new PlayN archetype changes the "mvn test -Pjava" configuration to run the game in such a way that -XstartOnFirstThread is properly provided when running on a Mac (annoyingly if you pass that to the JVM on Linux or Windows, the JVM refuses to run, so we have to do a bunch of conditional blah blah blah to be sure we can "write once, run everywhere").

If you want to change your existing project, remove this from yourgame/java/pom.xml:

          <plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>exec-maven-plugin</artifactId>
            <version>1.2.1</version>
            <executions>
              <execution>
                <phase>test</phase>
                <goals>
                  <goal>java</goal>
                </goals>
              </execution>
            </executions>
            <configuration>
              <mainClass>${mainClass}</mainClass>
            </configuration>
          </plugin>

and replace it with:

          <plugin>
            <artifactId>maven-antrun-plugin</artifactId>
            <version>1.6</version>
            <executions>
              <execution>
                <phase>test</phase>
                <configuration>
                  <target>
                    <!-- these shenanigans are needed to pass -XstartOnFirstThread on Mac OS
                         but not on other OSes where they would cause the JVM to fail, yay -->
                    <condition property="jvmarg" value="-XstartOnFirstThread" else="-Dfoo=bar">
                      <os family="mac"/>
                    </condition>
                    <java fork="true" classname="${mainClass}" classpathref="maven.test.classpath">
                      <jvmarg value="${jvmarg}"/>
                      <arg value="${scaleFactor}"/>
                    </java>
                  </target>
                </configuration>
                <goals>
                  <goal>run</goal>
                </goals>
              </execution>
            </executions>
          </plugin>

I'll release a playn-2.0-rc3 version in a day or two, once I've made sure that this doesn't horribly break everything for everyone.

So if you use 2.0-SNAPSHOT, please update to the latest code and give things a whirl.

Thanks!


Michael Bayne

unread,
Dec 21, 2015, 7:24:28 PM12/21/15
to pl...@googlegroups.com
On Mon, Dec 21, 2015 at 11:56 AM, Michael Bayne <m...@samskivert.com> wrote:
Anyhow, for the most part, this should be totally invisible to users of PlayN.

Well, not completely as it turns out. The -XstartOnFirstThread thing means that the "stock" LWJGL backend (which uses GLFW) can no longer use Swing/AWT for Input.getText and Input.sysDialog (on the Mac). Indeed, it can't use anything. They can't be made to work. Blah.

On Linux (and Windows, I presume) this is not a problem. GLFW and AWT get along fine, so things still work fine on those platforms.

I was at least able to get the java-swt backend working again, and that does support Input.getText and Input.sysDialog on all platforms (using SWT instead of AWT). It does not, unfortunately, support Retina displays though. So if you use that to develop on a Retina Mac (like I do), then you have to go back to the bad old days of blurry ugly PlayN. Blah.

Anyhow, this probably only affects me because most everyone is either on Windows or Linux, or doesn't use Input.getText/sysDialog or doesn't have a Retina Mac. So unhappy birthday to me.

Maybe SWT will eventually support Retina displays, but I'm not holding my breath.


Tom

unread,
Dec 21, 2015, 7:30:38 PM12/21/15
to PlayN
Happy birthday ;) 

Andrey Kleshchenko

unread,
Dec 22, 2015, 5:31:37 PM12/22/15
to PlayN
Good news!

Happy B Day Michael!

Michael Bayne

unread,
Dec 22, 2015, 6:22:28 PM12/22/15
to pl...@googlegroups.com
On Tue, Dec 22, 2015 at 2:31 PM, Andrey Kleshchenko <kles4enk...@gmail.com> wrote:
Happy B Day Michael!

It's not actually my birthday, I was just being dramatic. I should have said Merry Christmas to me.

For future reference, my birthday is in April. Feel free to send pull requests with awesome features at that time of year. :)

Jason

unread,
Dec 22, 2015, 8:25:32 PM12/22/15
to pl...@googlegroups.com

Wow, April 1st??? :) 

--

---
You received this message because you are subscribed to a topic in the Google Groups "PlayN" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/playn/HJPL6Bqo-c8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to playn+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Andrey Kleshchenko

unread,
Dec 23, 2015, 6:40:14 AM12/23/15
to PlayN
It's not actually my birthday, I was just being dramatic. I should have said Merry Christmas to me.
Oh... So, Marry Christmas! I hope you will get nice gift under the Christmas tree this year!
 
For future reference, my birthday is in April. Feel free to send pull requests with awesome features at that time of year. :)
Do we have a list of nice-to-have features? People can invest their time if they know what PlayN really need.


Mickael Barbeaux

unread,
Dec 28, 2015, 5:46:23 AM12/28/15
to PlayN
Tested on our own projects.

It works well on Win7 and Win 8.1.
Couldn't test on Linux but we can try by mounting a Ubuntu guest under VMWare if possible.
Didn't work on MacOSX Yosemite but the problem is that we use it as a VMWare guest operating system ; so LWJGL didn't want to initialize correctly because there is no OpenGL driver. (that was already the case with the LWJGL 2.0 implementation)

Merry holidays :)

Andrey Kleshchenko

unread,
Dec 28, 2015, 9:25:28 AM12/28/15
to PlayN
Just tested 2.0-SNAPSHOT on my Ludum Dare 33 entry on linux 64-bit (OpenSuse 42.1).
Works fine. Subjectively it is faster.

Michael Bayne

unread,
Dec 28, 2015, 12:30:15 PM12/28/15
to pl...@googlegroups.com
On Mon, Dec 21, 2015 at 11:56 AM, Michael Bayne <m...@samskivert.com> wrote:
I'll release a playn-2.0-rc3 version in a day or two, once I've made sure that this doesn't horribly break everything for everyone.

OK, I just shipped playn-2.0-rc3 in which LWJGL3 is the new default Java backend, but you can use the LWJGL2 backend by changing java-lwjgl to java-lwjgl2 in your java/pom.xml file.

If you use Input.getText or Input.sysDialog or develop on a Mac and don't want to have to use -XstartOnFirstThread, then maybe you want to stay with the LWJGL2 backend. I wish this "upgrade" could be a transparent backend change that was all upside, but alas technology never seems to cooperate.

Andrey Kleshchenko

unread,
Jan 3, 2016, 5:34:47 PM1/3/16
to PlayN
Hi Michael!

I've just found problem with GLFW in playn-2.0-rc3: keyboard sends  Keyboard.KeyEvent repeatedly while key is down.
It's a bit unexpected, because it worked correct with LWJGL 2. We received only two event: key pressed and released.

I did some investigation. Seems we need to enable 'sticky keys' in GLFW. Here is comment from GLFW.glfwSetInputMode() method (GLFW.java:2099):
Sets an input option for the specified window.
If mode is CURSOR, the value must be one of the following cursor modes:
...
If mode is STICKY_KEYS, the value must be either TRUE to enable sticky keys, or FALSE to disable it. If sticky keys are enabled, a key press will ensure that GetKey returns PRESS the next time it is called even if the key had been released before the call. This is useful when you are only interested in whether keys have been pressed but not when or in which order.

I tried with local snapshot copy with set this value to true inside GLFWInput constructor:
glfwSetInputMode(window, GLFW_STICKY_KEYS, GLFW_TRUE);
But it didn't help.

Operation system is Linux x64 with Gnome 3.16 as desktop environment.

Could you please, take a look at this issue.

Thanks,
Andrei

Reply all
Reply to author
Forward
0 new messages