-
-
Notifications
You must be signed in to change notification settings - Fork 1.2k
fix issues #1193 and #1558 for Linux/Windows (LWJGL v3 hangs) #1690
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
… in AppSettings. ‘CenterWindow’, ‘WindowXPosition’ and ‘WindowYPosition’ variables. This way these variable will be saved in the profile when the profile is saved, and be reloaded. I added ‘CenterWindow’ to be added with a ‘true’ value for the default value so it will run just like it did before. But if you set ‘CenterWindow’ to ‘false’ then inside LwjglWindow.java (lwjgl3 code) it will look at these new values, it will determine to center the window or use the position values to place the window back at the location the user last moved it to. Of course, these values are only updated if the “program” updates this value. So if you want to save screen position, you can save them on closing to and on restart put the window back into the same location.
LWJGL3-JME library would block the current thread when executing LWJGL3. Instead of calling run() that is blocking, made it work like LWJGL2-JME library when they start it as a thread so run gets called. I commented out the run() function and replaced it with Thread.start().
LWJGL3-JME projects was doing a call that is blocking the current thread. I changed it to match how LWJGL2-JME project launches the Context Window.
LWJGL3-JME projects was doing a call that is blocking the current thread. I changed it to match how LWJGL2-JME project launches the Context Window.
…TestApplication hangs with LWJGL3 jMonkeyEngine#1193 Made LWJGL3-JME to launch in the same way the LWJGL2-JME launches. This always Windows and Linux to run, still needs testing on Max OS X
|
This is also related to issue jme-lwjgl3 - bug for starting app #1514 |
|
From what I can tell you just reverted the changes? I can already tell you this breaks osx which is why it was changed in the first place. |
…estApplication hangs with LWJGL3 jMonkeyEngine#1193 Made LWJGL3-JME to launch in the same way the LWJGL2-JME launches. This always Windows and Linux to run, still needs testing on Max OS X
|
I made more changes, based on the history of the changes and other issues about this issue. It does end up checking to see if it is a Mac and do something else. This is solution I'm using on my engine, it needs to be tested but I worry there is not anyone to test for it. I will cross my fingers for one to step up to test. |
|
We should try to come up with code that doesn't use "magic guess the OS" string checks. Even if that means changing the semantics of what start() means. |
|
Sorry if this is a stupid question, but why use |
|
I found a way to check from inside LWJGL3, they have a call to return a ENUM for the 3 types of hardware that is support. I will put that in but last night my eclipse build started to mess up and I couldn't get it to run in debug to verify it. The enum returns, WINDOWS, LINUX or MAC. They even have a class to verify it is running on the main thread and return false is not, so you can throw an exception. |
|
I just confirmed that this crashes on OSX. |
…G3 class that determines this instead.
|
I made changes to remove the string comparison. This does fix the Windows and Linux. Jeddic, if you have a MAC, Please look into a solution for Mac. Looking into the JME-LWJGL2 library the create() method ends up doing the same for the Mac. This is moving forward to getting LWJGL3 functioning. I'm not sure what "CRASH" means, because it does the run() call on the current thread. If anything this is not a solution for Mac, but for other 2 OS. |
|
@Jeddic next time, please copy/paste the stack trace |
There you go. |
|
So I tested the current version and it is close, but calling mainthread.run() won't work. There isn't a runnable assigned so it immediately returns and closes the application. Just calling run() directly works for me. |
…ut the Linux and Windows version will start to work.
|
Jeddic, thanks. I but the run() call back for MacOS. This will not solve the issue for Mac and AWT but will for Linux and Windows. |
|
Yah, fixing it for osx will probably take changing the canvas to use the lwjgl-awt project. Let me know if there is anything else that needs to be tested. |
|
If this PR doesn't solve the issue for macOS, then why not remove the Also, our preferred Java style specifies that braces are used with |
|
Well, this pull request should fix the issue for windows / linux. The clause is there specifically so it doesn't break macOS in the process. |
|
I added the braces for the correct coding. We have to leave in the check for MAC, because the Mac needs the run() call. That call is blocking and non-returning. But with the thread().start(), that is a non-blocking call that will allow the return so the rest of the code gets executed after the call to app.start() in main. |
|
Rather than slog through another round of review, I fixed a couple minor issues and integrated the PR. Thank you for your contribution to the Engine! |
|
Now TestAWTPanels is broken in a new and different way. See issue #1558 for details. |
|
Okay, I checked in the changes and tested it against the example from the forum where it is hanging. |
|
Do I start a new merge request to get the changes over since it has already been merged. |
|
No need for that, it is already fixed in JME v3.5.0-beta5. See #1722. |
TestAWTPanels hangs with LWJGL v3 #1558 / jme3test.app.TestApplication hangs with LWJGL3 #1193
Made LWJGL3-JME to launch in the same way the LWJGL2-JME launches. This always Windows and Linux to run, still needs testing on Max OS X