LWJGL Forum

Please login or register.

Login with username, password and session length
Pages: 1 2 [3] 4 5 ... 10
 21 
 on: March 12, 2017, 13:30:58 
Started by rupy - Last post by rupy
So I'm thinking about building this C++ engine, but I really don't like working in C++/C, so I'm thinking of having the core engine be C++ and then you script the game in Java very similar to Unity. Has anything like this been done before.

Also do you know if there are many other small open source game engines like this one out there:

http://www.gameplay3d.io

 22 
 on: March 06, 2017, 20:39:24 
Started by pdid - Last post by Gojira
Ah, OK I think I get it.

So most GLFW functions need to be called on the main thread.

But the rendering context I get from `glfwCreateWindow` and `glfwMakeContextCurrent` can be used with OpenGL calls on any thread (assuming proper synchronization and mutex).

 23 
 on: March 06, 2017, 19:21:35 
Started by pdid - Last post by Kai
You are again mistaking GL functions for GLFW functions. You must separate between them. It is _always_ okay to call OpenGL/GL functions in any thread you like (given that that context is only current in one thread at a time).
The GLFW documentation is of course correct, but what is said there applies to _GLFW_ functions. NOT OpenGL/GL functions.
You find GLFW functions generally in the org.lwjgl.glfw.GLFW class and OpenGL functions in the org.lwjgl.opengl.* classes.

 24 
 on: March 06, 2017, 19:16:26 
Started by pdid - Last post by Gojira
...but Mac OS has a restriction that the original main thread must be used when calling OpenGL, is that correct?
No, this is not correct. What you mean are window manager API calls which are done inside glfwPollEvents() and glfwCreateWindow(), for example. Consult the GLFW api documentation to see which functions are safe to call in which threads.


Here's what the GLFW website says about threading.

Quote
Thread safety

Most GLFW functions must only be called from the main thread, but some may be called from any thread. However, no GLFW function may be called from any thread but the main thread until GLFW has been successfully initialized, including functions that may called before initialization.

The reference documentation for every GLFW function states whether it is limited to the main thread.

Initialization and termination, event processing and the creation and destruction of windows, contexts and cursors are all limited to the main thread due to limitations of one or several platforms.

Because event processing must be performed on the main thread, all callbacks except for the error callback will only be called on that thread. The error callback may be called on any thread, as any GLFW function may generate errors.

Source: http://www.glfw.org/docs/latest/intro_guide.html#thread_safety

Maybe I've got the wrong page but "most GLFW functions" sounds like a blanket statement to me.  I'm not trying to play games either I'm just learning and I want to make sure I am looking at the correct documentation.

 25 
 on: March 06, 2017, 17:52:19 
Started by Gojira - Last post by Gojira
There also looks to be some good OpenGL tutorials on Slide Share.  Here's one I found, and there's a lot of links on the right side to more OpenGL stuff.

https://www.slideshare.net/Mark_Kilgard/using-vertex-bufferobjectswell

 26 
 on: March 06, 2017, 17:48:56 
Started by pdid - Last post by Kai
...but Mac OS has a restriction that the original main thread must be used when calling OpenGL, is that correct?
No, this is not correct. What you mean are window manager API calls which are done inside glfwPollEvents() and glfwCreateWindow(), for example. Consult the GLFW api documentation to see which functions are safe to call in which threads.

With any OS you can use any threads to issue OpenGL commands in, including GLFW's glfwSwapBuffers() and glfwWindowShouldClose(). The only restriction regarding OpenGL calls is that any given OpenGL context must only be current in one and only one thread at any given time. You can change the current thread, though.

 27 
 on: March 06, 2017, 17:42:40 
Started by pdid - Last post by Gojira
I was thinking about doing something similar, but Mac OS has a restriction that the original main thread must be used when calling OpenGL, is that correct?

So to be portable one shouldn't use multiple threads inside OpenGL like this.  Or that's what I assumed.

 28 
 on: March 05, 2017, 21:19:10 
Started by Ray1184 - Last post by Gojira
I found this about a week ago and I agree it's very good.  A great job by the author.

 29 
 on: March 05, 2017, 21:18:25 
Started by BenderBending - Last post by Gojira
If you don't want to edit the pom.xml file, you can just download the zip file of LWJGL from GitHub.

Then unpack all the files, and in NetBeans go to Tools -> Libraries.  Create a New Library, call it "LWJGL" or something similar and add all the .jar files you just downloaded.  There's quite a lot so it'll take some time.

Then whenever you need a LWJGL project, just create "New Application" as usual and then click on the "Libraries" in the Projects view (far left screen, not the menu) and just Add Library.  Everything is already set up and you never have to manually modify your build file.  If you're creating lots of little projects (i.e., probably just learning) this is very convenient.

 30 
 on: March 05, 2017, 21:12:42 
Started by Gojira - Last post by Gojira
I found this recently, it seemed interesting.  I haven't read through the whole thing but it seems like a good explanaition of how modern graphics processing works.  It's aimed at "graphics programmers that know a modern 3D API (at least OpenGL 2.0+ or D3D9+)" so I thought other folks here might like to read and comment.

https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/

Pages: 1 2 [3] 4 5 ... 10