Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (697)
Games in Android Showcase (202)
games submitted by our members
Games in WIP (767)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1] 2 3 ... 10
 on: 2016-10-27 12:12:59 
Started by SolidGold - Last post by Spasi
Reckon the way to do this is to just forget the business about passing the context, set all "images" in main thread?

Doing everything on the main thread is a legitimate solution. Reasons for using secondary thread(s) include: a) decoupling the event loop from rendering and b) decoupling loading OpenGL assets from rendering (asynchronous loading of models, textures etc).

For the specific issue you're having with the window not responding, I would recommend simplifying your code and posting a sample that reproduces the freeze.

 on: 2016-10-27 11:08:20 
Started by SolidGold - Last post by SolidGold
Hmm. Reckon the way to do this is to just forget the business about passing the context, set all "images" in main thread? I don't care about openngl in the thread for anything other than loading images.

 on: 2016-10-27 10:58:42 
Started by SolidGold - Last post by SolidGold
You were right, I had misplaced glfwPollEvents(). They have been neutralized.

However my window still says (not responding) and draws nothing. I can tell it is doing stuff though (doing "more" I think). If I press esc it at least kills something in the window, but it still hangs. Could it hang like that if I had design flaws and it wasn't getting back to the main loop? But I'd think not since the esc key worked.

What you say does dictate 2 contexts then, yes? One for showing and one for operating on. What is the appropriate procedure for that? Kill first window and make new window?

 on: 2016-10-27 10:29:18 
Started by SolidGold - Last post by KaiHH
There are two things which are different:
- handling window events via glfwPollEvents/glfwWaitEvents()
- calling OpenGL methods / swapping buffers

The former MUST happen on the main thread.
The latter _may_ happen on any thread, but only one thread at a time.

When the window freezes it means that you do not process the former: handling window events.

Also note that an OpenGL context is directly 1:1 associated with a window. So when you talk about passing a context "back to a window", this is wrong. The context has always been associated with that single window.
The only thing that may change is the thread which calls OpenGL functions on behalf of that context.
So you can only attach/detach a thread to/from an OpenGL context. You _cannot_ detach/attach an OpenGL context to/from a window.

 on: 2016-10-27 10:26:05 
Started by SolidGold - Last post by SolidGold
That's a cool feature. Everything regarding setup is working now. Running from the jars you mentioned plus 2 for stb. No VM arguments.

I'm back to my original problem I think. This may be a conceptual flaw on my part now? I'm porting from a prior (non-LWJGL) build so I'd not be surprised to need such adjustments. I send the context to the game making thread so that it can work on that context.

- I no longer draw my loading screen. I understand why though (I think).
- I can't seem to get my context back to the window? The window freezes once I do glfwMakeContextCurrent(0L) (as I'd presume it should). Once the game making thread finishes, it runs through code that I would expect would at least send the context back to the window. However the window remains at "Not Responding". But I see that it passes that code, so I think my flaw is with passing the context around.

Conceptually, there is no way to get around using 2 contexts here, right? I should either:
A) Use 1 context for everything except the loading screen. Loading screen context draws, then back to main context with game.
B) 1 context for the opening part up to and including the loading screen, then a completely new context is created and passed back with the game.

Technical question:
How do I properly pass this context around? The three statements: glfwMakeContextCurrent(windowIn); GL.createCapabilities(); and glfwMakeContextCurrent(0L); at their appropriate, reciprocal locations?

Thank you!

 on: 2016-10-27 07:42:45 
Started by SolidGold - Last post by Spasi
Setting java.library.path or org.lwjgl.librarypath is not required. These two settings are still supported and used internally, but you shouldn't need them unless you're doing some customization (e.g. creating a platform-specific installer for your application).

LWJGL has something called the SharedLibraryLoader which takes care of extracting the native libraries from the natives JARs and loading them automatically. The only thing you need to do is add the JARs to the classpath. So, if for example you're making a GLFW+OpenGL application and are running on Windows, you'll have to set the classpath to include:


That's it. From the command line it's simple; if you have all LWJGL JARs in a subfolder called "lwjgl", you can do:

java -cp lwjgl/*;<other stuff here> my.application.Main

and it should just work. In Eclipse, or any other IDE, configure your project to include all the LWJGL JARs in the classpath.

 on: 2016-10-27 05:31:54 
Started by ziozio - Last post by ziozio
Saw this interesting blog article on game development workflow

 on: 2016-10-27 04:37:24 
Started by BurntPizza - Last post by philfrei
I've been working on a really nice particle system. I started work yesterday, it's come far enough for my liking, although dancing around Java2D's limitations is a bit of a headache.
A JavaFX particle system == fewer headaches?

 on: 2016-10-27 04:01:38 
Started by SolidGold - Last post by SolidGold
I made a new project so I could test this all out. I got as far as setting up my VM arguments, but it is still upset. So the code I'm using is that HelloWorld from the lwjgl site. All the code is happy but won't run.

I get:
[LWJGL] Loading library (system): lwjgl
[LWJGL]    lwjgl.dll not found in org.lwjgl.librarypath=<path>\lwjgl-3.1.0-custom
[LWJGL] [TLS] Failed to initialize unsafe implementation.
[LWJGL] ThreadLocalUtil state: TLState
Exception in thread "main" java.lang.NoClassDefFoundError: Could not initialize class org.lwjgl.system.MemoryAccess
   at org.lwjgl.system.Pointer.<clinit>(
   at org.lwjgl.system.Platform.mapLibraryNameBundled(
   at org.lwjgl.glfw.GLFW.<clinit>(
   at HelloWorld.main(

My VM arguments:
It had been a sole .dll before, but no .dll came with this package so I assumed this here.

I reckon it does want a .dll tho since it is looking for one? I didn't change anything when I downloaded this bundle, but no .dll inside.

 on: 2016-10-27 01:35:05 
Started by Ecumene - Last post by SHC
I'm doing it too.

Pages: [1] 2 3 ... 10
theagentd (26 views)
2016-10-24 17:51:53

theagentd (25 views)
2016-10-24 17:50:08

theagentd (26 views)
2016-10-24 17:43:15

CommanderKeith (42 views)
2016-10-22 15:22:05

Roquen (48 views)
2016-10-22 01:57:43

Roquen (58 views)
2016-10-17 12:09:13

Roquen (57 views)
2016-10-17 12:07:20

Icecore (74 views)
2016-10-15 19:51:22

theagentd (338 views)
2016-10-04 17:29:37

theagentd (342 views)
2016-10-04 17:27:27
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!